Technical File for IoT devices — concrete template aligned with CRA and RED

A Technical File for a connected IoT device — Wi-Fi camera, smart sensor, BLE wearable, LoRa gateway — follows the same eight-section structure as any CE-marked product, but adds depth in the cybersecurity-specific sections that the Cyber Resilience Act introduces from 11 December 2027. This article walks through a concrete IoT Technical File template, section by section, with what each must contain in 2026.

The structure aligns with CRA Annex VII (the modern reference for IoT in scope of CRA) and RED Annex V (for radio products under RED — most connected IoT). For products subject to both, the same Technical File satisfies both directives — the sections overlap and the manufacturer organises by section heading.

Template structure

The eight CRA Annex VII sections mapped to IoT-specific content:

Technical File — ConnectedSensor X1 (HW Rev C, FW v1.4.x)
═════════════════════════════════════════════════════════════

1. Product identification and description
2. Design and manufacturing
3. Risk assessment
4. List of harmonised standards applied
5. Test reports and verification records
6. Software-specific evidence (CRA Annex I Part II)
7. Conformity assessment record
8. Post-market surveillance plan
─────────────────────────────────────────────────────────────
Annexes (as needed): photographs, schematics, full test reports

Section 1 — Product identification and description

The first section answers what the product is.

For an IoT device, include:

• Product name and intended marketing description
• Type / model designation as it appears on the product label
• Hardware revision (Rev C, board v3)
• Firmware version range the Technical File covers (v1.4.x)
• Serial number range of units placed on the market under this Technical File version
• Intended use — what the product is for, in what environment, for what user type
• Foreseeable misuse — uses the manufacturer does not intend but anticipates (CRA Article 13 requires this for risk-assessment context)
• Connectivity profile — Wi-Fi 2.4/5 GHz, BLE, LoRa, cellular bands; protocols supported (MQTT, CoAP, HTTPS, custom)
• Target markets — EU/EEA, plus any extra-EU markets sharing the conformity claim
• High-resolution photograph or CAD render sufficient for traceability

Section 2 — Design and manufacturing

The engineering ground truth.

For an IoT device:

• Schematics — full electrical schematics with annotated power supply, communication interfaces, security peripherals (TPM, secure element if present)
• PCB layout — gerbers or PDF plots
• Mechanical drawings — enclosure, antenna placement, button and indicator positions
• Bill of materials with component manufacturer, part number, version, supplier
• Sub-component datasheets — radio module, microcontroller, power supply, sensor packages, secure element
• Software architecture diagram — application layers, RTOS or OS, drivers, secure boot chain, update mechanism, telemetry pipeline
• Manufacturing process description — PCB assembly, programming, calibration, testing in production

Section 3 — Risk assessment

A documented analysis of the risks the product presents and the measures mitigating them. Per CRA Article 13(2), the risk assessment is proportional to the product's intended use and foreseeable misuse.

For an IoT device, the risk assessment covers:

• Electrical and thermal hazards — methodology typically per EN 62368-1 (the harmonised safety standard for ITE; consult the standard for binding methodology)
• Electromagnetic hazards — EMC emissions and immunity per EN 55032 and EN 55035 (consult the standards for binding test methods)
• Radio hazards — RF exposure, spurious emissions per EN 301 489 series and EN 300 328 for 2.4 GHz (consult the standards)
• Cybersecurity hazards — asset-based methodology per EN 18031 Annex A (for products in scope of RED Delegated Act and CRA Annex I)

Asset-based cybersecurity risk assessment maps:

• Identified assets — what the product holds or controls that has value (user data, network functionality, update mechanism, payment functions if applicable)
• Identified threats per asset — STRIDE-style enumeration or equivalent threat-modelling approach
• Required security capabilities to mitigate each identified threat — authentication, encryption, integrity protection, secure update, logging
• Residual risks accepted by the manufacturer with rationale and any user-disclosed mitigations

See CRA Annex I explained for the security capability list aligned with this methodology.

Section 4 — List of harmonised standards applied

Every standard cited by full reference and version date.

A typical IoT device DoC cites approximately:

• EN 18031-1:2024 — cybersecurity requirements for radio equipment (RED Delegated Act + foundational for CRA)
• EN 18031-2:2024 — personal data and privacy protection
• EN 18031-3:2024 — fraud protection
• EN 62368-1:2014+A11:2017 — safety
• EN 55032:2015+A11:2020 — EMC emissions
• EN 55035:2017+A11:2020 — EMC immunity
• EN 301 489-1 V2.2.3 + EN 301 489-17 V3.2.4 — radio EMC (or as currently cited in OJ)
• EN 300 328 V2.2.2 — Wi-Fi/BLE 2.4 GHz (as cited in OJ)
• EN IEC 63000:2018 — RoHS technical documentation

Verify each version against the Official Journal harmonised standards listing on the date of DoC signing.

Section 5 — Test reports and verification records

The compliance evidence.

For an IoT device:

• EMC emissions test report — lab name, ISO/IEC 17025 accreditation, date, method, results vs limits
• EMC immunity test report — same structure
• Radio test report per RED Annex II — band-of-operation, output power, spurious emissions, modulation
• Safety test report under EN 62368-1 — touch current, dielectric strength, temperature rise
• Cybersecurity test results per EN 18031 — functional and conformity tests for each implemented security capability
• RoHS conformity declaration from each component supplier, or in-house testing for representative samples

For each test report, retain the methodology, lab credentials, date, test article description (which hardware revision and firmware version was tested), acceptance criteria, and pass/fail conclusion.

Section 6 — Software-specific evidence

The CRA-specific section that distinguishes an IoT Technical File from a non-connected product.

Required content per CRA Annex I Part II:

6.1 — Software Bill of Materials

A machine-readable SBOM in CycloneDX or SPDX format per release. See SBOM CycloneDX vs SPDX for format details.

6.2 — Secure update mechanism design

• Cryptographic signing of update packages
• Integrity verification on download
• Rollback protection logic
• Distribution channel (HTTPS, manufacturer CDN)
• User-facing update notification design
• Out-of-band update mechanism for systems unable to receive standard updates

6.3 — Coordinated vulnerability disclosure policy

• Public CVD policy URL and /.well-known/security.txt
• Researcher communication channel (email, web form, platform)
• Acknowledgement and remediation timelines
• VEX statement publication channel

6.4 — Vulnerability handling procedures

• Vulnerability triage process (severity classification with CVSS or equivalent)
• Patch SLA per severity tier
• CVE issuance and advisory publication workflow
• CRA Article 14 reporting workflow trigger and escalation

6.5 — Security event logging

• What is logged (authentication, configuration changes, update events, anomalous access)
• Local retention policy
• Remote forwarding option and configuration
• User opt-out mechanism

6.6 — Cryptographic algorithm inventory

• Algorithms used, key sizes, where applied (TLS, signing, at-rest encryption)
• Deprecation plan when algorithms become weak

6.7 — Build pipeline and security testing evidence

• SAST tool results per release
• DAST tool results per release
• Dependency scanning results per release
• Threat-modelling exercise summary per major release

Section 7 — Conformity assessment record

The procedural evidence.

For most IoT consumer products, this is:

• Module(s) applied per cited directive (typically Module A for LVD/EMC/RoHS and CRA standard products; Module B+C/H for CRA important products in Annex III)
• Justification for module choice (Module A available when harmonised standards are fully applied)
• Notified Body details if applicable (NB number, name, certificate reference)
• Date of conformity assessment completion

Section 8 — Post-market surveillance plan

What happens after the product ships.

For an IoT device:

• Field data collection — customer support tickets, telemetry-derived metrics (opt-in), warranty returns
• Incident triage workflow — who classifies a customer report as a potential security incident
• CRA Article 14 reporting escalation — internal escalation criteria that map to "actively exploited vulnerability" or "severe incident" thresholds
• CVD researcher communication — how the manufacturer handles inbound researcher reports
• Regulation monitoring — how the manufacturer tracks Official Journal amendments to cited directives and standards
• Review cadence — when the Technical File and DoC are formally re-assessed (typically annually or per major release)

How Cenitia generates the IoT Technical File

Cenitia ingests your product description, BOM, software architecture, intended markets, and uploaded engineering artefacts. The output is a pre-populated eight-section Technical File aligned with CRA Annex VII and RED Annex V, with the SBOM-driven vulnerability monitoring already integrated. Citations to specific EUR-Lex articles and harmonised standards are baked in; revisions trigger automatic checks against the latest OJ-cited standard versions.

For high-complexity products that need Notified Body review of the Technical File before Module B+C/H submission, our parent company Inovasense provides expert preparation and audit response.

Frequently asked questions

Does an IoT device need a different Technical File from any other CE-marked product?

Structurally no — the CRA Annex VII and RED Annex V section headings apply to all in-scope products. What an IoT device adds is depth in specific sections: an SBOM section under the CRA Annex VII vulnerability handling subsection, a secure update mechanism description, a vulnerability disclosure policy, security event logging design, and cybersecurity-specific risk assessment. The general directive structure (LVD, EMC, RoHS) sections remain similar to a non-connected product.

What goes in the IoT Technical File that does not go in a non-IoT Technical File?

The CRA-specific evidence under Annex VII section on the manufacturer's processes: SBOM in CycloneDX or SPDX, secure update mechanism design and test results, coordinated vulnerability disclosure policy, vulnerability handling procedures, security event logging architecture, cryptographic algorithm inventory, and the cybersecurity risk assessment per Article 13 of CRA. The non-connected Technical File omits these but adds, for non-IoT physical products, more detailed mechanical drawings and physical safety test reports.

Does the Technical File need to contain source code?

Generally no. The CRA Annex VII and RED Annex V do not require source code disclosure. The Technical File documents the software architecture, the SBOM, the secure development practices, and the build pipeline at a level sufficient for an auditor to understand the product's compliance — without requiring access to proprietary source. Notified Bodies under Module B or H may request specific source-code review for security-critical components on a case-by-case basis, typically under non-disclosure.

How do I keep the Technical File in sync with continuous software updates?

Version-control the Technical File alongside the firmware. Each firmware release that materially changes the cybersecurity posture triggers a Technical File update: new SBOM, updated vulnerability handling records, refreshed risk assessment if threat model changes. Cosmetic firmware updates (UI tweaks, performance optimisations without security impact) do not necessarily trigger a TF update but most teams version-track them anyway for traceability.

Where do I store the IoT Technical File electronically?

Version-controlled storage in any format that can be reproduced promptly on authority request. Common approaches: Git repository with the Technical File as Markdown / PDF artifacts, cloud document management system (Confluence, SharePoint), or specialist compliance platforms. The format requirement under Regulation 2019/1020 Article 18 is that the file be available promptly in the language the authority specifies — the storage medium itself is unprescribed.

Can I host the Technical File partially with my EC REP if my company is outside the EU?

Yes. Under CRA Article 13(2)(a) the EU Authorised Representative is required to keep a copy of the Declaration of Conformity and the Technical File at the disposal of market surveillance authorities for ten years. The original responsibility for compiling and updating the Technical File remains with the manufacturer; the EC REP's copy must be kept current as the manufacturer's master copy updates. Many EC REP services include a secure document portal for synchronised Technical File hosting.

Related from the Library

• Technical File 101 — pillar context covering all CE-marked products
• CRA Annex I explained — the essential requirements section 6 evidences
• SBOM CycloneDX vs SPDX — section 6.1 detail
• RED Delegated Act + EN 18031 walkthrough — the cybersecurity standard family
• CRA timeline and reporting obligations — the Article 14 workflow in section 8

Further reading

• Cyber Resilience Act Annex VII — Technical Documentation
• Radio Equipment Directive Annex V — Technical Documentation
• Regulation 2019/1020 Article 18 — Technical documentation availability
• Blue Guide — Chapter 4 on Technical Documentation

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