ETSI EN 303 645: what it asks of a product list

The consumer IoT baseline standard behind the PSTI regime's deemed-compliance route. Held here at provision-group level (5.0 to 5.13 and 6): the provisions are cited by group, not one by one, and no individual provision is stated.

The provisions are cited by group (5.1, 5.2, 5.3, 5.7), never one by one; the individual provisions are not stated here.

Duties by role

Role	Clauses
manufacturer	ETSI EN 303 645 5.1 (provision group) No universal default passwords ETSI EN 303 645 5.2 (provision group) Implement a means to manage reports of vulnerabilities ETSI EN 303 645 5.3 (provision group) Keep software updated
importer	none here
distributor	none here
own brand (becomes the manufacturer)	ETSI EN 303 645 5.1 (provision group) No universal default passwords ETSI EN 303 645 5.2 (provision group) Implement a means to manage reports of vulnerabilities ETSI EN 303 645 5.3 (provision group) Keep software updated

Notes that cite it

Note	Clause
5. No support period stated, or under five years with no reason recorded	ETSI EN 303 645 5.3 (provision group) ETSI EN 303 645 5.7 (provision group)
6. A universal default password	ETSI EN 303 645 5.1 (provision group)
7. No published vulnerability contact	ETSI EN 303 645 5.2 (provision group)
8. No security update mechanism, or unsigned updates	ETSI EN 303 645 5.3 (provision group) ETSI EN 303 645 5.7 (provision group)

ETSI EN 303 645: every clause cited

4 of the 15 held

The requirement text is our statement of each clause, read against the copy we hold and cited to it; it is not the instrument verbatim.

ETSI EN 303 645 5.1 (provision group)No universal default passwords

Where passwords are used and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user. Pre-installed unique per-device passwords shall be generated by a mechanism that reduces the risk of automated attacks against a class or type of device.

What a notified body or authority asks to see: Per-device unique-password generation evidence; User-set password enforcement at first use

Where lists usually fall short: Single shared default password across the product line; Predictable per-device defaults

Source: ETSI EN 303 645 (consumer IoT baseline)

ETSI EN 303 645 5.2 (provision group)Implement a means to manage reports of vulnerabilities

The manufacturer shall make available to the public a vulnerability disclosure policy, including a contact for the disclosure of vulnerabilities and an acknowledgement timeline; received reports shall be acted on within a reasonable time, with status updates to the reporter.

What a notified body or authority asks to see: Published vulnerability disclosure policy and contact; Disclosure-pipeline records and SLA evidence

Where lists usually fall short: No published disclosure policy; No acknowledgement / triage process

Source: ETSI EN 303 645 (consumer IoT baseline)

ETSI EN 303 645 5.3 (provision group)Keep software updated

Software components in consumer IoT devices shall be securely updateable; the manufacturer shall publish a defined support period during which security updates are provided; updates shall be timely and shall not adversely affect the function of the device. Where the device is not updateable, the rationale, replacement period and disposal information shall be published.

What a notified body or authority asks to see: Defined and published support period; Secure update mechanism (signed, integrity-checked); Update-history records

Where lists usually fall short: No published support period; Updates without integrity protection; No replacement guidance for non-updateable devices

Source: ETSI EN 303 645 (consumer IoT baseline)

ETSI EN 303 645 5.7 (provision group)Ensure software integrity

Consumer IoT devices shall verify their software using secure boot mechanisms, and a verifiable record shall be available. If an unauthorised change is detected, the device shall alert and limit functionality.

What a notified body or authority asks to see: Secure-boot design and verification evidence; Unauthorised-change detection and response behaviour

Where lists usually fall short: No secure boot; No integrity check on critical software components

Source: ETSI EN 303 645 (consumer IoT baseline)