Cyber

Regulation

ETSI EN 303 645: the 13 consumer IoT security requirements, explained

By Dorian

September 22, 2026

5 min read

The 13 requirements of the ETSI EN 303 645 standard for consumer IoT

If you were to read only one framework before designing a connected device, it would be this one. ETSI EN 303 645 runs to about forty pages, can be read without legal training, and describes the security baseline every consumer product should meet.

We cite it regularly in our articles. Here, finally, is what it contains, requirement by requirement, with what each one means on a real product.

A voluntary standard, but everywhere

ETSI EN 303 645 is a European standard published by ETSI in 2020, whose current version is V3.1.3 from September 2024. It targets consumer connected devices: cameras, speakers, locks, toys, watches, home appliances, home gateways.

It is voluntary. No European text requires compliance with it. Yet it serves as a reference for many schemes around the world: the UK law on connected product security takes up its first three requirements, and several national cybersecurity labels are based on it.

Two documents accompany it:

ETSI TS 103 701, which describes how to assess a product’s conformity
ETSI TR 103 621, an implementation guide with examples

The 13 requirements

1. No universal default password

Each device must have a unique password, or require the user to set one. It is the first requirement because it is the leading cause of mass compromise. See our training on the default password.

2. A way to receive vulnerability reports

The manufacturer publishes a disclosure policy: a point of contact, and a commitment on response times. A researcher who finds a flaw must know whom to write to.

3. Software kept up to date

The product can receive security updates, in a way that is simple for the user. The manufacturer states how long it will provide them.

4. Secure storage of sensitive parameters

Keys, credentials and certificates are protected in the device. No secret shared by all products is hardcoded. This is exactly the subject of Secrets in the firmware: three flaws, one root cause.

5. Secure communications

Exchanges are encrypted and authenticated with state-of-the-art mechanisms, whether they go over the Internet or a local link. Our articles on Bluetooth Low Energy and MQTT show what happens when that is not the case.

6. A reduced attack surface

Unused interfaces and services are disabled. This includes physical interfaces: the standard explicitly mentions debug ports. See JTAG and SWD: debug interfaces from the attacker’s side.

7. Software integrity

The product verifies its software at boot and reacts to unauthorized modification. See Secure boot and firmware signing.

8. Protection of personal data

Personal data is encrypted in transit, especially the most sensitive. The device’s sensors (microphone, camera) are clearly documented for the user.

9. Resilience to outages

The product keeps performing its local functions when network or power is lost, and resumes cleanly afterwards. A smart lock must remain a lock when the cloud stops responding.

10. Examination of telemetry data

If the product reports usage or measurement data, it is examined to detect security anomalies.

11. Easy deletion of user data

Users can erase their data from the device and associated services, simply, with clear confirmation. The question arises with every resale or product return.

12. Simple installation and maintenance

Secure configuration requires as few decisions as possible from the user, and the product guides them. A security setting nobody can find is a setting nobody turns on.

13. Validation of input data

Any data received through an interface, network or otherwise, is checked before use. This is the basic rule of secure development, applied to APIs and to internal buses as well.

The standard ends with a chapter dedicated to personal data protection: user information, consent, telemetry minimization.

Gap between the product sheet and the audit findings

Reading the standard from the attacker’s side

Presented like this, the list seems obvious. It is not, for a simple reason: each requirement is easy to tick on paper and hard to hold on the product.

What the product sheet says	What the auditor finds
“Unique password per device”	A password derived from the MAC address, and therefore computable
“Encrypted communications”	TLS to the cloud, and a local Bluetooth link in clear
“Secure updates”	An HTTPS download of a firmware that is not signed
“Debug interfaces disabled”	A connector removed, signals still active on the pads
“Protected secrets”	The same API key in every firmware

The standard also distinguishes mandatory provisions from recommendations, and specifies for each the conditions under which it applies. Assessment according to TS 103 701 requires the manufacturer to justify each point, not just to assert it.

How does it relate to the CRA and the RED directive?

The three texts largely overlap in substance, not in status.

	ETSI EN 303 645	RED directive (EN 18031)	Cyber Resilience Act
Nature	Voluntary standard	Legal obligation	Legal obligation
Scope	Consumer IoT	Connected radio equipment	All digital products
In application	Since 2020	From August 1, 2025, until December 10, 2027	Reporting since September 2026, full in December 2027
Lifecycle	Partial	Barely covered	Covered in detail

ETSI EN 303 645 does not give a presumption of conformity with the RED or the CRA. However, a product designed to meet it already covers a large part of the technical requirements of both. It is a good starting point, readable by a product team, before moving on to the mandatory texts.

For details, see RED directive and EN 18031 and Cyber Resilience Act: what has applied since September 11, 2026.

How to use it

At the start of a project, as an architecture checklist. Thirteen questions to ask before freezing the hardware.
In a call for tenders, as a requirement for a supplier. Asking for the declaration of conformity requirement by requirement is more effective than a general clause. See also our 5 questions to ask before buying a connected device.
Before placing on the market, as an audit framework. Each requirement can be verified by a test.
In training, as a common thread. Each requirement corresponds to an attack that can be reproduced.

The link with our trainings

Our trainings follow this logic: for each requirement, show on real hardware what happens when it is not met, then how to meet it. The IoT Security path covers most of the thirteen points, from the default password to firmware signing. The program is detailed in our training programs.