ETSI EN 303 645: the consumer IoT security baseline, explained

EN 303 645 is published by ETSI, titled "Cyber Security for Consumer Internet of Things: Baseline Requirements". It specifies high-level security and data-protection provisions for consumer IoT devices that connect to network infrastructure, such as the internet or a home network; the standard's own scope describes consumer IoT devices as network-connected devices typically used in the home or as electronic wearables, and it explicitly excludes industrial, healthcare and manufacturing-focused devices from its scope. Examples it covers in practice: smart home hubs, connected cameras, speakers, locks, appliances and wearables.

The standard has gone through several published and draft versions:

Always check ETSI's own deliverables directory for the current version before citing a clause number, since the provision numbering has shifted slightly between major versions (early drafts used clause 4.x; V2.1.1 onward uses clause 5.x). The change history in Annex C of V3.1.3 traces the line back to ETSI TS 103 645 V1.1.1 (February 2019): V2.1.1 turned it into an EN and expanded it to 68 provisions, and TS 103 645 V3.1.1 (January 2024) revised it "to improve applicability and testability" before V3.1.3 was adopted as an EN on 11 September 2024. V3 voids some V2 provisions and splits others, such as 5.3-4 into 5.3-4A and 5.3-4B, so provision IDs in an old checklist need re-mapping.

EN 303 645's requirements sit in clause 5, split into 13 provisions:

Clause 6 adds data protection provisions (6-1 to 6-8), for example clear information to consumers about what personal data is processed and on what basis. The provisions are written to be outcome-focused rather than prescriptive, giving manufacturers flexibility in how they meet each one rather than mandating a specific technical mechanism. Provision 5.1, no universal default passwords, is the one most often lifted into law or policy on its own: where passwords are used, in any state other than the factory default, every device password must be unique per device or set by the user, and a unique default must not be derivable from public information or the device's own identifiers unless hashed or encrypted to good industry practice.

"Shall" provisions are mandatory; "should" provisions are recommendations. Clause 4 of the standard says the "should" provisions give flexibility because applicability depends on the device. Provision 5.0-1 then makes the flexibility auditable: a justification "shall be recorded for each recommendation" that is not applicable or not fulfilled.

Annex B (Table B.1) is the pro forma for that record. Each provision carries a status, M (mandatory) or R (recommendation), and sometimes C (conditional) or F (applies only if the feature exists); the manufacturer fills in Y, N or N/A and a detail column. ETSI lets users reproduce and publish the completed table. For the three provisions regulators lean on most, V3.1.3 marks:

A "should" can be skipped with a reasoned justification; a "shall" cannot, unless its own condition (such as a use-case resource constraint) takes it out.

EN 303 645 sets what a consumer IoT device should do. The companion specification, ETSI TS 103 701, sets out how to test and assess a product against each of those 13 provisions: it is the conformance assessment specification referenced from EN 303 645's own introduction. A manufacturer, lab or certification scheme that wants to claim conformity with EN 303 645 in a structured, repeatable way uses TS 103 701 as the test methodology rather than inventing its own.

TS 103 701 V2.1.1 (May 2025) is written against EN 303 645 V3.1.3 and supports self-assessment, second-party and third-party assessment; defining a certification scheme is out of its scope. Its inputs are the Implementation Conformance Statement (ICS), which is the completed Table B.1, and the Implementation eXtra Information for Testing (IXIT), design detail that lets the lab run grey-box tests. Test cases are either conceptual (assessing the documented design) or functional (checked on the device under test). Missing or thin IXIT answers can lead to an INCONCLUSIVE verdict.

The UK's mandatory Product Security and Telecommunications Infrastructure (PSTI) regime enforces three Schedule 1 requirements: no universal default or easily guessable passwords, a published vulnerability-reporting contact with acknowledgement and status-update commitments, and a disclosed minimum security-update period. These map closely onto EN 303 645's first three provisions (5.1-5.3), and the UK government's own PSTI product security regime page lists EN 303 645 among its supporting standards and guidance resources. PSTI compliance, however, does not require certifying against the full 13-provision standard; it is a narrower, legally mandatory subset.

The link is written into the law. Schedule 2 of the PSTI Regulations 2023, in force since 29 April 2024, treats a manufacturer as complying with a Schedule 1 requirement if it meets the matching EN 303 645 provisions:

The Regulations define "ETSI EN 303 645" as V2.1.1 (June 2020), so check those provisions against that version even when you build to V3.1.3. See UK PSTI and US Cyber Trust Mark for device makers for PSTI's full legal detail, dates and penalties, and the PSTI statement of compliance guide for the document itself.

EN 303 645 is voluntary in the EU. No formal Official Journal citation making it a harmonised standard for the EU Cyber Resilience Act or the RED cybersecurity delegated act (EN 18031) could be found at the time of writing, so a claim that conforming to EN 303 645 gives presumption of conformity under either EU regime should not be assumed. EN 303 645 and EN 18031 are separate standards from separate bodies, not alternates for each other, but the engineering overlaps. An indicative mapping, for planning only:

The CRA also asks for an SBOM and incident reporting, which EN 303 645 does not. See CRA Annex I explained, EN 18031 explained for firmware teams and the Cyber Resilience Act requirements. A number of national and sector consumer-IoT labelling or assessment schemes outside the UK are commonly described as drawing on EN 303 645 as a reference baseline; check any specific scheme's own current documentation before relying on it.

Synthetic example. The product and answers are invented for illustration.

A Wi-Fi smart plug pairs through a phone app, has no screen and no camera, and updates over the air. An excerpt of its Table B.1:

The 5.1-2A entry is a recommendation marked "N" with a reason, which 5.0-1 allows. In a TS 103 701 assessment, the lab would ask for IXIT detail on how the label code is generated and test the signature check functionally.

• Deriving "unique" passwords from the MAC address or serial number. 5.1-2 and PSTI both reject this unless a keyed hash or encryption to good practice is used.
• A disclosure policy without timelines. 5.2-1 asks for acknowledgement and status-update timelines, not only an email address; see our vulnerability disclosure policy template and the ISO/IEC 29147 and 30111 process guide.
• "N/A" without a reason. Every not-applicable or not-supported entry needs a justification in the detail column.
• Citing V3.1.3 provision IDs in a PSTI file without checking the V2.1.1 equivalents the law references.
• Signed updates, unsigned recovery path. A USB or serial recovery mode that skips verification undercuts 5.3-10 and 5.7.
• Forgetting the app and cloud. The scope includes the device's interactions with associated services.

SoftWSP's platform extracts a CycloneDX SBOM from a submitted firmware image and matches the identified components against NVD, CISA KEV, FIRST EPSS and CISA CSAF ICS advisories. AI drafts the report from those matches, citing the record behind each finding, and an engineer reviews it before it ships. That evidence supports 5.2-3 (monitor for and fix vulnerabilities) and the update decisions under 5.3; see firmware SBOM. Checks such as hard-coded credentials (5.1) or update signing (5.3, 5.7) are done by an engineer in a service engagement, not by the automated scan. SoftWSP does not assess conformance itself, does not replace ETSI TS 103 701 testing, and never invents a provision match the evidence does not support.

SoftWSP builds the SBOM and vulnerability evidence behind EN 303 645, UK PSTI, EU CRA and EN 18031 work: see device firmware security.

This guide is general information, not legal advice.