A CRA technical file should function as a controlled evidence index for the exact product version placed on the market. It should allow a reviewer to move from product identity to cybersecurity risks, Annex I requirements, architecture and controls, vulnerability handling, verification evidence and the final conformity conclusion. Article 31 requires this technical documentation before market placement and requires it to be continuously updated where appropriate, at least during the support period.
Use Technical File as a Practical Term, Not the Formal CRA Title
Article 31 formally uses the term technical documentation. Annex VII defines the content of that technical documentation. The Regulation does not prescribe a separate document formally titled a CRA technical file. In practice, manufacturers may use technical file as a convenient name for the organised collection, index or controlled evidence package containing the required documentation. Keeping this distinction clear prevents an internal document-management convention from being presented as though it were the wording of the Regulation.
- Formal CRA term: technical documentation.
- Practical working term: technical file.
- Use Annex VII as the minimum content map.
- Keep internal filing conventions separate from legal terminology.
Build the File Before the Product Is Placed on the Market
Article 31 requires the technical documentation to be drawn up before the product with digital elements is placed on the market. Article 13 also requires manufacturers, before market placement, to draw up the technical documentation and carry out or have carried out the chosen conformity assessment procedure. The technical file should therefore be assembled during product development and release preparation rather than reconstructed after commercial launch.
- Begin evidence collection during development.
- Complete the applicable Annex VII package before market placement.
- Align the package with the release candidate.
- Resolve missing evidence before conformity assessment.
Start With a Technical Documentation Index
A practical technical file begins with an index that identifies the product, release or build, evidence owner, document revisions and controlled locations of the required records. Article 31 does not prescribe one mandatory folder structure. The manufacturer can organise evidence in a document-management system, controlled repositories or another suitable system, provided that the required information can be identified and produced reliably. The index should act as navigation rather than duplicate every document.
- Product identifier.
- Compliance-relevant release.
- Evidence identifier.
- Document version.
- Evidence owner.
- Controlled evidence location.
- Approval or status.
Section 1: General Product Description
Annex VII begins with a general description of the product with digital elements. The technical file should include the intended purpose, versions of software affecting compliance with essential cybersecurity requirements, hardware photographs or illustrations where the product is a hardware product, and the user information and instructions required by Annex II. This section establishes which marketed product the rest of the evidence describes.
- Intended purpose.
- Versions of software affecting compliance.
- Hardware photographs or illustrations where applicable.
- External features, marking and internal layout where applicable.
- Annex II user information and instructions.
Define the Product and Release Boundary Precisely
The file should make clear which hardware, software, firmware, cloud components and deployment profile belong to the assessed product version. A reviewer should not have to guess whether an architecture diagram describes version 2.1 while a test report describes version 1.8. Use product identifiers, build identifiers and document versions consistently. Where one evidence record applies to several variants, record the applicability explicitly.
- Product model.
- Hardware revision where relevant.
- Software and firmware version.
- Build identifier.
- Product edition.
- Deployment profile.
Section 2A: Design, Development and System Architecture
Annex VII requires necessary information on the design and development of the product and, where applicable, drawings, schemes and a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing. The technical file can therefore index product-boundary diagrams, component architecture, interfaces, trust boundaries, important data flows and other design records needed to understand the security-relevant structure of the product.
- Design and development information.
- Drawings and schemes where applicable.
- System architecture.
- Software component relationships.
- Interfaces and trust boundaries.
- Security-relevant data flows.
Add Security Design Evidence
Security design documentation is a practical layer connecting the cybersecurity risk assessment and Annex I requirements to the technical architecture. It can show where authentication, access control, secure defaults, confidentiality, integrity, resilience, attack-surface limitation, exploit mitigations, logging, monitoring, update security and secure data removal are implemented. The CRA does not require a document with the exact title security design document, but the underlying design evidence can demonstrate the means used to satisfy Annex I.
- Security requirements.
- Annex I control mapping.
- Implementing components.
- Security design rationale.
- Assumptions and dependencies.
- Verification references.
Section 2B: Vulnerability Handling Processes
Annex VII requires necessary information and specifications about the vulnerability handling processes established by the manufacturer. This expressly includes the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for vulnerability reporting and a description of the technical solutions chosen for the secure distribution of updates. The technical file should point to the current controlled versions of these records and identify which product releases they cover.
- Software bill of materials.
- Coordinated vulnerability disclosure policy.
- Vulnerability-reporting contact evidence.
- Secure update-distribution solution.
- Vulnerability handling procedure.
- Product-version applicability.
Section 2C: Production and Monitoring Processes
Annex VII also requires necessary information and specifications concerning the production and monitoring processes of the product with digital elements and the validation of those processes. The technical file should therefore identify the relevant build, production, release and monitoring controls that help ensure the marketed product remains aligned with the assessed design. The evidence should also show how those processes have been validated where required.
- Production process.
- Build and release controls.
- Monitoring processes.
- Production security controls.
- Process validation evidence.
Section 3: Cybersecurity Risk Assessment
Annex VII requires an assessment of the cybersecurity risks against which the product is designed, developed, produced, delivered and maintained pursuant to Article 13, including how the essential cybersecurity requirements in Part I of Annex I are applicable. The technical file should therefore include or reliably reference the current cybersecurity risk assessment, threat and attack scenarios, applicability decisions, risk treatment records and relevant residual-risk conclusions.
- Cybersecurity risk assessment.
- Intended purpose and foreseeable use context.
- Threat and attack scenarios.
- Annex I applicability.
- Risk treatment decisions.
- Residual risk.
Make Annex I Traceability Easy to Follow
A requirement-to-evidence matrix can make the technical file easier to review. For each applicable Annex I requirement, identify the relevant risk, product or process control, design record and verification evidence. The CRA does not prescribe one mandatory traceability-matrix format. The value of the matrix is navigation: a conformity reviewer should be able to find the evidence supporting each important compliance conclusion without searching through unrelated engineering records.
- Annex I reference.
- Applicability decision.
- Risk reference.
- Control reference.
- Design evidence.
- Verification evidence.
Section 4: Support-Period Determination
Annex VII requires the relevant information that was taken into account to determine the support period pursuant to Article 13. The technical file should preserve the factors used by the manufacturer rather than only the resulting end date. Evidence can include expected product use, reasonable user expectations, product nature and intended purpose, relevant Union law, operating-environment availability, third-party component support and other relevant considerations identified by Article 13.
- Expected product use.
- Reasonable user expectations.
- Nature and intended purpose of the product.
- Relevant Union law.
- Operating-environment availability.
- Core third-party component support.
- Declared support period.
Section 5: Standards, Specifications and Technical Solutions
Annex VII requires a list of applicable harmonised standards used in full or in part, relevant common specifications and applicable European cybersecurity certification schemes. Where those routes have not been applied, the technical documentation should describe the solutions adopted to meet the Annex I requirements and list other relevant technical specifications. Where a standard, common specification or certification scheme has been applied only partly, identify the parts applied.
- Harmonised standards applied.
- Parts applied where use is partial.
- Common specifications.
- Relevant European cybersecurity certification schemes.
- Alternative technical solutions.
- Other technical specifications.
Do Not Treat a Standards List as the Complete Compliance Case
A standards list is one part of Annex VII rather than a replacement for the product-specific cybersecurity risk assessment, architecture, vulnerability handling and verification evidence. Where a manufacturer relies on a standard, the technical file should identify the version or reference used and the relevant scope. Where the standard is only partly applied, document which parts were used and how remaining CRA requirements were addressed.
- Record the exact standard reference.
- Record whether application is full or partial.
- Identify uncovered CRA requirements.
- Link remaining requirements to other technical solutions.
Section 6: Security and Conformity Test Reports
Annex VII requires reports of the tests carried out to verify conformity of the product with digital elements and of the vulnerability handling processes with the applicable essential cybersecurity requirements in Parts I and II of Annex I. The technical file should identify which product version was tested, what requirement or control was verified, the test environment, expected result, actual result, findings, remediation and retest evidence.
- Test report identifier.
- Tested product version.
- Annex I requirement.
- Test scope and environment.
- Expected and actual result.
- Findings.
- Remediation.
- Retest evidence.
Include Both Product and Vulnerability-Process Verification
The Annex VII testing requirement covers both the product and the vulnerability handling processes. Product evidence can verify access control, confidentiality, integrity, resilience, attack-surface controls, security updates and other applicable Part I properties. Process evidence can verify SBOM generation, vulnerability intake, remediation workflows, disclosure processes and secure update distribution under Part II. One generic penetration test does not prove every CRA requirement.
- Part I product-security verification.
- Part II vulnerability-process verification.
- Risk-based testing.
- Process validation.
- Requirement-specific evidence.
Section 7: EU Declaration of Conformity
Annex VII requires a copy of the EU declaration of conformity. The technical file should ensure that the declaration corresponds to the same product identity and version represented by the supporting technical evidence. Article 13 requires the manufacturer to draw up the declaration after the applicable conformity assessment has demonstrated compliance and to affix the CE marking in accordance with the Regulation.
- Copy of the EU declaration of conformity.
- Correct product identity.
- Consistent release information.
- Applicable conformity route.
- Traceability to supporting evidence.
Section 8: Understand the Additional SBOM Provision
Annex VII also refers, where applicable, to the software bill of materials further to a reasoned request from a market surveillance authority where the SBOM is necessary for that authority to check Annex I compliance. This provision should not be read as meaning that manufacturers only need to create an SBOM after an authority asks for one. Annex I Part II independently requires manufacturers to identify and document components and draw up an SBOM covering at least top-level dependencies, and Annex VII point 2(b) includes the SBOM within vulnerability handling documentation.
- Maintain the operational SBOM.
- Associate it with product releases.
- Understand the market-surveillance request provision.
- Keep the two Annex VII SBOM references distinct.
Include Conformity-Procedure Evidence Where Applicable
The technical documentation supports the conformity assessment required by Article 32. Depending on the applicable procedure, additional records can include internal-control evidence, notified-body correspondence, certificates, quality-system records or other procedure-specific material. These records do not replace Annex VII. They sit alongside the Annex VII package where the chosen conformity route requires them.
- Chosen conformity procedure.
- Procedure-specific evidence.
- Notified-body correspondence where applicable.
- Certificates where applicable.
- Quality-system evidence where applicable.
Use One Technical Documentation Set Where Article 31 Allows It
Article 31 provides that where products referred to in Article 12 are also subject to other Union legal acts that require technical documentation, a single set of technical documentation is to be drawn up containing the Annex VII information and the information required by those other Union acts. Manufacturers should therefore avoid maintaining conflicting evidence packages where a properly controlled combined set is appropriate.
- Identify other applicable Union technical-documentation obligations.
- Use one controlled set where Article 31 applies.
- Preserve all CRA Annex VII content.
- Avoid inconsistent duplicate records.
Control the Language of Conformity Documentation
Article 31 states that technical documentation and correspondence relating to a conformity assessment procedure must be drawn up in an official language of the Member State in which the notified body is established or in a language acceptable to that body. Where a notified body is involved, manufacturers should therefore confirm language requirements before submitting the evidence package rather than assuming every internal engineering language will be accepted.
- Identify notified-body language requirements.
- Control translated evidence where necessary.
- Keep translated and source versions traceable.
Baseline the File Against the Released Product
Immediately before the conformity and release decision, create a controlled evidence baseline for the actual product version being placed on the market. The baseline should identify the risk assessment, architecture, security design, SBOM, vulnerability handling documentation, support-period evidence, standards mapping, test reports and EU declaration associated with that release. Avoid relying on a moving development branch as the only evidence of the released compliance state.
- Released product version.
- Build identifier.
- Evidence versions.
- Approval state.
- Release date.
- Superseded evidence where relevant.
Run a Completeness Review Before Conformity Assessment
A final completeness review can compare the file directly against Article 31, Annex VII and the applicable Annex I requirements. Check for missing product identifiers, unresolved risks, unexplained non-applicability decisions, stale architecture, unsupported standards claims, failed tests without retest evidence and vulnerability processes that differ from their documentation. This review should identify gaps while engineering and compliance teams can still resolve them.
- Annex VII completeness.
- Annex I traceability.
- Risk-assessment completeness.
- Evidence-version consistency.
- Open test findings.
- Vulnerability-process consistency.
- Conformity-route readiness.
Keep the Technical File Current During the Support Period
Article 31 requires technical documentation to be continuously updated where appropriate, at least during the support period. The controlled technical file should therefore change when compliance-relevant software versions, architecture, dependencies, risk conclusions, vulnerability processes, security controls, standards or test evidence change. Updating the file should not erase the evidence baseline for earlier marketed versions.
- Review product changes.
- Update affected evidence.
- Preserve historical baselines.
- Repeat affected tests.
- Maintain current vulnerability-handling documentation.
Retain the Technical Documentation for the Required Period
Article 13 requires manufacturers to keep the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer. Technical-file storage should therefore support long-term retrieval, integrity and migration rather than depend only on short-lived development tools.
- At least 10 years after market placement.
- Or the support period where longer.
- Preserve technical documentation.
- Preserve the EU declaration of conformity.
- Plan for long-term evidence accessibility.
A Practical CRA Technical File Structure
One practical structure is to organise the evidence package into product identification, user information, architecture and security design, vulnerability handling, production and monitoring, cybersecurity risk assessment, support-period determination, Annex I traceability, standards and specifications, security test reports, conformity-procedure evidence, the EU declaration of conformity and version-control records. The CRA does not prescribe one mandatory folder structure. The structure should make Annex VII completeness and product-version traceability easy to demonstrate.
- 01 Product identification and intended purpose.
- 02 Annex II user information.
- 03 Architecture and security design.
- 04 Vulnerability handling and SBOM.
- 05 Production and monitoring processes.
- 06 Cybersecurity risk assessment.
- 07 Annex I requirements mapping.
- 08 Support-period evidence.
- 09 Standards and technical specifications.
- 10 Security and conformity testing.
- 11 Conformity-procedure evidence.
- 12 EU declaration of conformity.
- 13 Evidence index and version history.
Final CRA Technical File Readiness Check
A technical file is ready when the evidence package describes the actual product version, covers the applicable Annex VII content, explains the Article 13 cybersecurity risks, shows how Annex I requirements are implemented, contains current vulnerability handling documentation, identifies the standards or technical solutions used, includes the required test reports and declaration, and can be maintained and retrieved throughout the required lifecycle. The objective is not document volume. The objective is a coherent and traceable compliance case.
- Correct product version.
- Complete Annex VII evidence.
- Current cybersecurity risk assessment.
- Annex I traceability.
- Current vulnerability handling evidence.
- Complete test evidence.
- EU declaration of conformity.
- Controlled maintenance and retention.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.