ETSI EN 303 645 and the Cyber Resilience Act
The consumer-IoT security baseline that accredited labs and candidate CRA notified bodies test against. Every provision produces evidence you can reuse in a CRA technical file.
Where EN 303 645 fits in CRA compliance
ETSI EN 303 645 is the established baseline for consumer connected products. It predates the CRA and covers much of the same ground as the CRA Annex I essential requirements, so a product tested against it already holds a large part of the evidence a CRA technical file needs. Laboratories that test consumer IoT, including organisations positioning themselves as CRA notified bodies, use it as their reference test standard.
It is a supporting standard, so applying it does not by itself grant presumption of conformity with the CRA. That legal bridge only exists once a standard is cited in the Official Journal of the EU. The value here is practical. Structure your evidence to EN 303 645 and most of it carries straight into the CRA assessment.
ETSI EN 303 645
ETSI EN 303 645 V2.1.1, Cyber Security for Consumer Internet of Things, Baseline Requirements
A baseline of cybersecurity provisions for consumer IoT devices, widely used as the reference test standard for connected consumer products in the EU.
Not a CRA harmonised standard
Published ETSI standard. It is not a CRA harmonised standard, so applying it does not confer presumption of conformity with the CRA. It is a strong evidence baseline for Annex I and the standard that accredited consumer-IoT labs test against.
| Provision | Requirement & how the platform helps | CRA reference |
|---|---|---|
| 5.1 | No universal default passwords Passwords are unique per device or defined by the user, not a shared factory default. STRIDE spoofing threats and Annex I authentication controls are tracked against the product record. | Annex I Part I (2)(d) |
| 5.2 | Implement a means to manage reports of vulnerabilities The manufacturer operates a coordinated vulnerability disclosure process and publishes a policy. The public disclosure portal, CVD policy page, security.txt, and intake/triage workflow satisfy this directly. | Annex I Part II (1)-(2) |
| 5.3 | Keep software updated Devices receive timely, secure software updates for a defined support period. Security-review scheduling, CSAF advisory publication, and update-distribution tracking. | Annex I Part I (2)(c) |
| 5.4 | Securely store sensitive security parameters Credentials and keys are stored securely, not hard-coded in device software. Data-at-rest threats catalogued and mapped to Annex I confidentiality controls. | Annex I Part I (2)(e) |
| 5.5 | Communicate securely Security-relevant data in transit is protected with encryption appropriate to the use case. Data-in-transit STRIDE threats and secure-communication controls tracked per product. | Annex I Part I (2)(e)-(f) |
| 5.6 | Minimise exposed attack surfaces Unused interfaces are closed and the principle of least functionality is applied. Unnecessary-functionality threat modelling and attack-surface review in the STRIDE catalogue. | Annex I Part I (2)(j) |
| 5.7 | Ensure software integrity Software is verified using secure boot mechanisms and tampering is detectable. Tampering threats and integrity controls captured in the threat model and evidence set. | Annex I Part I (2)(f) |
| 5.8 | Ensure that personal data is secure Personal data is processed securely and only as necessary. Data-minimisation and disclosure threats mapped to Annex I data-protection controls. | Annex I Part I (2)(e),(g) |
| 5.9 | Make systems resilient to outages Devices remain functional and recover cleanly after loss of power or network. Availability-degradation threats and resilience controls recorded in the assessment. | Annex I Part I (2)(h) |
| 5.10 | Examine system telemetry data Telemetry is examined for security anomalies where collected. Monitoring and logging obligations tracked through the vulnerability-monitoring workflow. | Annex I Part I (2)(l) |
| 5.11 | Make it easy for users to delete user data Users can erase their personal data and settings from the device. Deleted-data and data-removal threats catalogued against the product. | Annex I Part I (2)(m) |
| 5.12 | Make installation and maintenance of devices easy Secure setup is straightforward and guidance is provided to users. Documented in the technical-file assembly and user-guidance evidence. | Annex I Part II (7) |
| 5.13 | Validate input data Data received via interfaces and networks is validated before processing. Tampering and elevation-of-privilege threats around input handling in the STRIDE model. | Annex I Part I (2)(f) |
Turn EN 303 645 testing into a CRA technical file
Track your threat model, SBOM, and vulnerability handling in one place, then export an Annex VII dossier.