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

A Technical File documents the assessed product and the evidence supporting its applicable requirements. The eight folders below are an editorial organisation, not mandatory section numbering shared by every CE-marked product.

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). A combined evidence repository can support more than one act, but only a requirement-by-requirement cross-check establishes coverage. The CRA is a regulation. RED covers the radio equipment’s safety and EMC requirements; standalone LVD and EMC do not also apply to that equipment.

Template structure

An illustrative eight-folder structure; maintain a separate RED Annex V and CRA Annex VII coverage checklist:

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 method within its verified scope)
• 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 using a documented product-specific method; check applicable EN 18031 requirements and OJ restrictions using the licensed standard. EN 18031 is not automatically a CRA-harmonised risk-assessment method.

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 assessment evidence supporting the applicable RED requirements and chosen assessment route — 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 (record the actual route under each applicable act. For radio equipment, RED Article 17 distinguishes safety/EMC from spectrum and Article 3(3) assessment. CRA Article 32 has separate class-specific rules; Class I internal control depends on the coverage conditions, while Class II generally uses B+C or H, subject to the qualifying Article 32(5) software exception)
• Justification for module choice (availability depends on the applicable act, requirements, classification and coverage conditions)
• 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)

Using Cenitia for this work

Cenitia helps prepare evidence-linked working drafts within its supported regulatory catalogue. Confirm the product scope, actual applied standards and completed assessments, and review the result before issuance. Source-change alerts prompt a review; they do not certify conformity, automatically reissue a signed declaration or guarantee monitoring of every national rule and standard edition.

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 14(4)(a) — Market-surveillance powers to request technical information
• Blue Guide — Chapter 4 on Technical Documentation