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

ETSI EN 303 645 is the European Telecommunications Standards Institute's baseline standard for consumer Internet of Things (IoT) security: 13 outcome-focused provisions covering passwords, vulnerability disclosure, updates, secure storage, secure communication and more. It is voluntary on its own, but it is the direct ancestor of the UK's mandatory PSTI password, reporting and update-disclosure rules, and it is the baseline most consumer-IoT security checklists and labelling schemes still point back to.

What EN 303 645 is and who publishes it

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:

Version	Date	Status
V2.0.0	25 November 2019	Draft
V2.1.0	17 April 2020	Final draft
V2.1.1	29 June 2020	First published EN
V3.1.2	10 June 2024	Final draft
V3.1.3	24 September 2024	Current published EN

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 13 baseline provisions

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

#	Provision
5.1	No universal default passwords
5.2	Implement a means to manage reports of vulnerabilities
5.3	Keep software updated
5.4	Securely store sensitive security parameters
5.5	Communicate securely
5.6	Minimise exposed attack surfaces
5.7	Ensure software integrity
5.8	Ensure that personal data is secure
5.9	Make systems resilient to outages
5.10	Examine system telemetry data
5.11	Make it easy for users to delete user data
5.12	Make installation and maintenance of devices easy
5.13	Validate input data

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.

EN 303 645 vs. ETSI TS 103 701: baseline vs. assessment

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.

How it relates to UK PSTI

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. See UK PSTI and US Cyber Trust Mark for device makers for PSTI's full legal detail, dates and penalties.

What it does not give you

EN 303 645 is voluntary. 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; treat any claim that conforming to EN 303 645 gives presumption of conformity under either EU regime as to be confirmed, not assumed. 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; this guide has not independently verified each such scheme's current mapping, so check any specific scheme's own current documentation before relying on it. For the EU's own connected-device rules, see Cyber Resilience Act requirements and EN 18031 explained for firmware teams; EN 303 645 and EN 18031 are separate standards from separate bodies, not alternates for each other.

A workable starting process

1. Treat the 13 provisions as your baseline design checklist even before any regulator requires it; EN 18031, the CRA's Annex I and PSTI all overlap heavily with the same password, update, storage, communication and vulnerability-handling themes.
2. Start with provisions 5.1 to 5.3 (passwords, vulnerability reporting, updates); they are the ones most frequently turned into hard legal requirements, as PSTI shows.
3. Use ETSI TS 103 701 as your test plan, not an informal internal checklist, if you want a conformity claim a customer or auditor can actually verify.
4. Keep EN 303 645 evidence separate from your CRA, EN 18031 or PSTI compliance files, even where the underlying engineering work overlaps, since each is a distinct legal or voluntary instrument with its own scope and status.

SoftWSP scans consumer IoT firmware against the EN 303 645 baseline alongside UK PSTI, EU CRA and EN 18031 requirements, and builds the SBOM and vulnerability evidence behind all of them: see device firmware security.

This guide is general information, not legal advice.