Technical File 101 — what it must contain and how to maintain it

The Technical File (sometimes called the Technical Documentation under newer regulations) is the body of evidence behind every CE-marked product's Declaration of Conformity. It is what a manufacturer relies on to defend the signed claim that the product meets every applicable EU directive — and what market surveillance authorities and Notified Bodies inspect when investigating an incident or auditing a product family.

This guide walks through what the Technical File must contain in 2026, the specific additions the Cyber Resilience Act introduces for products with digital elements, retention and language rules, format requirements, the most common mistakes, and how Cenitia automates the structure.

What the Technical File is — and is not

The Technical File is the evidence package that makes the Declaration of Conformity defensible. The DoC is a single-page legal declaration; the Technical File is the body of work behind it. They are distinct documents serving distinct audiences:

Conflating the two is the most common first-time-manufacturer mistake. A signed DoC without a defensible Technical File behind it is a signature on a claim that cannot be substantiated when challenged.

What the Technical File must contain

Each directive specifies the required content (typically in an Annex). The structures overlap heavily — once you have built one Technical File, the second is largely a re-arrangement. The canonical modern reference is the Cyber Resilience Act's Annex VII, which lists eight required sections, mirrored by Annex VII of RED, Annex II of MDR, and Annex VII of the Machinery Directive.

1. Product identification and description

The first section answers "what product is this and what is it for?":

• Product name, model number, type designation, batch or serial number range
• Intended use (purpose, environment, target user)
• Foreseeable misuse — uses the manufacturer does not intend but anticipates
• Target markets within the EU (and outside if relevant)
• High-quality photographs, CAD renders, or labelled diagrams sufficient for traceability
• Brand owner if different from manufacturer

2. Design and manufacturing drawings

The engineering ground truth:

• Schematics, PCB layouts, mechanical drawings, assembly drawings
• Bill of materials with component manufacturers and part numbers
• Sub-component datasheets — at least for items material to safety or compliance (radio modules, power supplies, microcontrollers)
• Software architecture diagram, where software is non-trivial
• Manufacturing process description, particularly where critical to compliance

3. Risk assessment

A documented analysis of:

• Identified hazards (electrical, mechanical, EMC, cybersecurity, biological, ergonomic)
• Severity × probability matrix per hazard
• Risk-reduction measures applied (design changes, protective measures, user instructions)
• Residual risks accepted by the manufacturer and disclosed to the user

For machinery, EN ISO 12100 is the canonical methodology; for medical devices, ISO 14971; for cybersecurity under CRA, threat modelling against STRIDE or ISO/IEC 27005 is standard practice.

4. List of harmonised standards applied

Every cited standard by full reference and version:

• Standard number (e.g. EN 18031-1:2024, EN 55032:2015+A11:2020, EN 62368-1:2014+A11:2017)
• Date or year of the cited version
• Justification when a standard is only partly applied
• Demonstrated equivalence when alternative evidence replaces a standard

The harmonised standards list per directive is in the Official Journal; track changes — when a standard is replaced, the Technical File must reflect the current cited version.

5. Test reports and verification records

The compliance evidence:

• EMC test reports — emission and immunity, lab name, accreditation (ISO/IEC 17025), date, method
• Radio test reports per RED Annex II if applicable
• Safety test reports under EN 62368-1, EN 60601-1, or the applicable safety standard
• Cybersecurity test reports under EN 18031 (when in force in the Official Journal) or interim equivalents
• Pre-compliance and final tests both — auditors look for both

6. Software-specific evidence (where applicable)

Under the Cyber Resilience Act, products with digital elements add a substantial dedicated section. See CRA Annex I explained for the requirements being demonstrated. The Technical File evidence includes:

• Software Bill of Materials (SBOM) in CycloneDX or SPDX format, updated per release
• Secure update mechanism description — signing, integrity check, rollback, distribution channel
• Vulnerability handling policy — triage, SLA per severity, communication plan
• Cryptographic algorithm inventory — what algorithms, what key sizes, what protocols
• Security event logging design — what is logged, retention, format
• Coordinated vulnerability disclosure policy
• Build pipeline description — SAST, DAST, dependency-scan results
• Threat model per major release

7. Conformity assessment record

The procedural evidence:

• Which conformity assessment module(s) were applied (Module A, B+C, H, etc.) per cited directive
• Notified Body identification (NB number, name, address) and certificate references where applicable
• Supporting calculations and equivalence demonstrations when alternative methods replace harmonised standards
• Date of conformity assessment completion

8. Post-market surveillance plan

What happens after the product ships:

• How field data is collected (customer support, RMA data, telemetry where opted-in)
• How incidents are triaged and escalated
• Thresholds that trigger regulatory notifications (Article 14 CRA ENISA notification, RAPEX for consumer products, EUDAMED for medical devices)
• Review cadence — when the Technical File and DoC are formally re-assessed
• Vulnerability management process per CRA Annex I Part II requirements

Format, language, and retention

Format

The Technical File may be electronic or paper. In practice almost every modern manufacturer maintains it electronically — version-controlled repositories (Git, document management systems, cloud drives) all qualify under Article 18 of Regulation 2019/1020. The single requirement: it must be producible promptly when an authority requests, in the language the authority specifies, with a reasonable deadline.

Practical hygiene: do not depend on a specific cloud vendor or proprietary file format that may not exist in ten years. PDF/A, plain Markdown, and IEC 82079-compliant formats are durable choices.

Language

The Technical File may be drawn up in any official EU language. When a market surveillance authority requests it, they specify the language the manufacturer must produce it in. Most manufacturers maintain the master in English and translate only when explicitly required. The Declaration of Conformity has stricter language rules — see DoC 101.

Retention

The clock starts the day the last unit of the model leaves the manufacturer's possession for the EU market. Discontinuing the product does not reset the clock.

Maintenance — the Technical File is a living document

The most common second-year mistake is treating the Technical File as a one-time deliverable. It must be kept current through:

• Product changes. Hardware revision, software update, firmware upgrade — any change material to compliance updates the corresponding section
• Regulation amendments. When a cited directive is amended (CRA revision, RED delegated act update) the Technical File must reflect the new requirements
• Harmonised standard updates. When the Official Journal cites a new version of a standard, update the corresponding section
• Post-market findings. Field incidents, vulnerability disclosures, recalls — append to the post-market surveillance section
• Notified Body audit findings. Where applicable, corrective actions from NB audits become part of the file

Cenitia watches every cited regulation and standard for amendment and flags affected Technical Files automatically. See How Cenitia maps your product.

Common mistakes

From the Inovasense compliance practice and Cenitia review pipeline:

• No risk assessment, or a generic copy-pasted one. Auditors immediately recognise generic risk assessments — concrete hazards, severity, and mitigation specific to your product are what auditors look for.
• Citing harmonised standards without version dates. "EN 55032" is ambiguous. "EN 55032:2015+A11:2020" is auditable. The exact version determines the test methods that were applied.
• No SBOM under CRA scope. CRA Annex VII section explicitly requires it. A connected product without an SBOM in the Technical File fails Annex VII compliance from day one.
• Test reports without lab accreditation evidence. EMC, safety, and radio test reports must reference an ISO/IEC 17025-accredited lab or include the basis for the alternative method. Reports from non-accredited labs are routinely rejected.
• No post-market surveillance plan. Modern directives — MDR, CRA, RED with cybersecurity — require an explicit post-market plan in the Technical File. Its absence is a common withdrawal trigger.
• Treating the Technical File as the DoC's appendix. They are distinct documents. The DoC is signed; the Technical File supports it. Combining them confuses auditors and weakens the legal claim.
• No version control or change log. When a Notified Body asks "what version of the Technical File was in force when this product was placed on the market?", you must be able to answer.

How Cenitia helps

Cenitia generates a structured Technical File draft from your product description, uploaded engineering documents (BOM, schematics, datasheets, test reports), and selected applicable directives. The output is the eight-section Annex VII structure pre-populated with what your inputs already cover and a gap list for what remains. Citations to specific EUR-Lex articles and harmonised standards are baked in at draft time; revisions trigger automatic re-checking against the latest cited versions.

For products that need Notified Body review of the Technical File, or full lifecycle compliance management, our parent company Inovasense provides consulting.

Frequently asked questions

What is the difference between a Technical File and a Declaration of Conformity?

The Declaration of Conformity is the one-page legal statement the manufacturer signs to claim that a product meets all applicable EU directives. The Technical File is the evidence bundle — typically tens to hundreds of pages — that supports that statement. Customers see the DoC; market surveillance authorities and Notified Bodies inspect the Technical File on request.

How long must a Technical File be kept?

Ten years from the date the last unit of the product was placed on the EU market for most directives — including the Cyber Resilience Act (Annex VII), Radio Equipment Directive, Low Voltage Directive, EMC Directive, and Machinery. The Medical Device Regulation extends retention to 10 or 15 years depending on device class. Retention applies to both the Technical File and the Declaration of Conformity.

Can a Technical File be kept entirely in electronic form?

Yes, under Article 18 of Regulation 2019/1020 the Technical File can be in any format provided it is available promptly when requested by a market surveillance authority and can be produced in the official language of the authority. Cloud storage, version-controlled repositories, and document management systems all satisfy the requirement. The manufacturer must ensure long-term accessibility — including beyond the lifetime of any specific software vendor used to store it.

What language must the Technical File be in?

It may be drawn up in any official EU language. When a market surveillance authority requests it, the authority specifies which official language the manufacturer must provide it in, with a reasonable deadline. Most manufacturers maintain the Technical File in English and rely on translation only when an authority explicitly requests another language.

Does an SBOM belong in the Technical File?

Yes — under the Cyber Resilience Act Annex VII the Technical File must contain a Software Bill of Materials in a commonly used machine-readable format (CycloneDX or SPDX). The SBOM is updated per product release and retained alongside the rest of the Technical File for the full retention period.

Who can inspect the Technical File?

Market surveillance authorities of any EU member state can request it under Regulation 2019/1020. Notified Bodies inspect it as part of conformity assessment. Customs authorities can request it at the border when goods arrive in the EU. Customers and distributors do not have a right to inspect the Technical File — they receive the Declaration of Conformity. EC REPs (for non-EU manufacturers) must hold a copy on behalf of the manufacturer.

What happens if the Technical File is incomplete when requested?

Under Article 14(4) of Regulation 2019/1020, an incomplete Technical File is treated as a presumption of non-conformity. The authority can demand remediation within a deadline; failure to remediate triggers product withdrawal orders, market bans, and administrative fines per the national implementing law. Repeated incompleteness can escalate to criminal proceedings for knowing violations.

Related from the Library

• CE Marking 101 — umbrella pillar covering the whole CE process
• Declaration of Conformity 101 — the document the Technical File supports
• CRA Annex I explained — the cybersecurity requirements the software-specific section evidences
• Conformity assessment Modules A–H — which module is reflected in the Technical File

Further reading

• Cyber Resilience Act Annex VII — Technical Documentation
• RED Annex V — Technical Documentation
• MDR Annex II — Technical Documentation
• Regulation 2019/1020 — market surveillance, Article 18 on technical documentation
• Blue Guide — Chapter 4 on Technical Documentation

Last reviewed: 20 June 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.