ETSI EN 303 645 — the 13 consumer IoT controls explained

ETSI EN 303 645 was released by the European Telecommunications Standards Institute on 30 June 2020 and is positioned as the global baseline for consumer IoT cyber security. The latest stable version is v3.1.3, adopted in September 2024. The companion test specification ETSI TS 103 701 provides the conformance assessment methodology, with v2.1.1 published in May 2025.

EN 303 645 takes an outcome-based approach: it describes 13 high-level provisions in section 5, each broken into more granular numbered provisions marked Mandatory (M) or Recommended (R). It is referenced informatively in Annex C of each part of EN 18031, the harmonised standard listed in Commission Implementing Decision (EU) 2025/138 for the RED Delegated Act 2022/30. EN 303 645 itself, however, does not appear in the OJEU listing — it is a baseline, not a harmonised standard.

Document structure: 13 high-level provisions in section 5

EN 303 645 is organised in eight sections. Section 5 — "Cyber security provisions for consumer IoT" — is where the 13 high-level controls live. Each control has the form 5.x and is then broken into individually numbered provisions (5.x-1, 5.x-2, etc.), marked Mandatory or Recommended. Section 6 covers data protection provisions, with section 7 listing implementation conformance statement requirements.

Below is the canonical structure of section 5.

5.1 — No universal default passwords

The most cited provision in the standard. Manufacturers must not ship devices with universal default passwords (the same password baked into every unit of the same product). Where pre-installed unique passwords are used, they must be generated using a mechanism that reduces the risk of automated attacks against the broader class of devices.

The provisions in 5.1 also address authentication mechanisms against the device (local login) and machine-to-machine authentication. Brute-force protections — such as exponential backoff or temporary lockouts — are required on authentication interfaces.

5.2 — Implement a means to manage reports of vulnerabilities

Manufacturers must publish a vulnerability disclosure policy at minimum containing contact information for reporting and timelines for acknowledgement and status updates. The policy must be public-facing and reachable without authentication. The expectation is that reporters can submit findings without fear of legal retaliation and that the manufacturer treats reports as material input to update planning.

This provision aligns conceptually with the Cyber Resilience Act Annex I Part II vulnerability handling duties applicable from December 2027 — although CRA goes further (24-hour exploited-vulnerability reporting to ENISA, mandatory SBOM in technical documentation).

5.3 — Keep software updated

The provisions require that all software components on the consumer IoT device — including operating system, third-party libraries and the manufacturer's own application code — are updateable, unless the manufacturer documents a justified exception (for example, immutable firmware verified by hardware-backed secure boot).

Provision 5.3-13 requires that the manufacturer publish a defined support period for security updates. This is the single most consequential commitment in the standard from a business-model perspective: the support period must be visible to the consumer at the point of purchase.

5.4 — Securely store sensitive security parameters

Cryptographic keys, password hashes, OTA update signing certificates and other sensitive parameters must be stored using mechanisms that protect them from tampering and extraction. Where hardware-backed secure storage is available (TPM, secure element, ARM TrustZone, secure enclave), it must be used.

Hard-coded sensitive security parameters in device software source code are explicitly disallowed.

5.5 — Communicate securely

All data transmitted between the device, associated services and any companion app must use cryptographic protocols appropriate to the sensitivity of the data. Certificate validation must be implemented correctly — anti-pattern: accepting any certificate without validation. Mutual authentication is required for critical security functions and for management interfaces.

The provision covers Wi-Fi, Bluetooth, Zigbee, Thread, cellular and any other communication channel — there is no "low-risk LAN" exception.

5.6 — Minimise exposed attack surfaces

Apply the principle of least functionality. Unused services, ports, debug interfaces and protocols must be disabled by default in shipping firmware. Where physical debug interfaces (UART, JTAG) are exposed, they must be either physically inaccessible in the final product or logically disabled in production builds. Code that runs with elevated privileges must be minimised.

Documentation of all enabled services and the rationale for each is expected as part of the conformance evidence.

5.7 — Ensure software integrity

Verified secure boot is the canonical implementation. The device must verify the integrity of its software using a hardware root of trust. If an integrity check fails, the device must enter a defined state — typically refusing to boot or rolling back to a known-good firmware image — and notify the user, the administrator or the associated service.

This is the provision that most clearly distinguishes products with a hardware secure element from those that retrofit security at the application layer.

5.8 — Ensure that personal data is secure

Personal data transmitted between the device and associated services must be encrypted in transit. Personal data stored on the device must be protected using mechanisms appropriate to the sensitivity. Consumers must be informed about what personal data is processed, by whom and for what purpose, in a clear and prominent manner.

This provision is the bridge between cyber security and GDPR (Regulation (EU) 2016/679) data protection by design and by default obligations.

5.9 — Make systems resilient to outages

The device must remain operational, where possible, when external services or networks are unavailable. The standard expects the manufacturer to consider the consequences of network loss — a smart lock that fails open or fails closed has very different safety properties — and to design for graceful degradation and orderly reconnection. DDoS-resilience and rate-limit handling on associated services also fall under this section.

5.10 — Examine system telemetry data

Where telemetry is collected, it must be examined for security anomalies. The standard does not require devices to collect telemetry — it requires that, if collected, it is actually used to detect anomalous behaviour, not just stored. This provision is a recommended (R) outcome in most cases, but mandatory for devices with associated services that collect security-relevant data.

5.11 — Make it easy for users to delete user data

Users must be able to delete personal data stored on the device and on associated services using a straightforward mechanism. Clear instructions must be provided. Confirmation that the deletion has occurred is required. This applies both to single-data-item deletion (e.g. delete a recording) and to full factory reset before resale or disposal — the latter being the more common audit failure.

5.12 — Make installation and maintenance of devices easy

The device's initial setup must not require the user to circumvent or weaken security to complete it. Setup guidance, including any configuration steps, must be available and accessible. Where ongoing maintenance is required (firmware updates, certificate renewal, password rotation), the device must support these operations without specialist tools or knowledge.

A common failure mode under TS 103 701 testing is a setup flow that requires the user to disable TLS verification or accept self-signed certificates on the first onboarding step.

5.13 — Validate input data

All data received from user interfaces (touchscreens, buttons, voice), network interfaces (Wi-Fi, Bluetooth, USB) and any other input channel must be validated before use. Validation must cover both format (length, type, encoding) and semantic plausibility. This protects against buffer overflows, injection attacks, and protocol parsing vulnerabilities — the most common root cause of CVEs in IoT firmware.

This provision is the most engineering-heavy of the 13: it requires code review and (ideally) fuzz testing of every input parser.

TS 103 701 — the test specification

ETSI TS 103 701 is the conformance assessment specification companion to EN 303 645. It defines structured test cases — typically one or more per mandatory provision — and the assessment outcomes ("Pass", "Fail", "N/A", "Pending"). It also defines the documentation that a manufacturer must produce: the Implementation Conformance Statement (ICS) and the Implementation eXtra Information for Testing (IXIT).

Without TS 103 701, EN 303 645 is a statement of outcomes. With TS 103 701, it is an auditable conformance scheme. Almost every national consumer IoT labelling programme — UK PSTI, Singapore Cybersecurity Labelling Scheme, Finland Tietoturvamerkki, Germany IT-Sicherheitskennzeichen — references TS 103 701 as the conformance method.

Where EN 303 645 fits into the EU regulatory map

EN 303 645 is not a harmonised standard under the Radio Equipment Directive (Directive 2014/53/EU). The harmonised standards for RED Article 3(3)(d), (e) and (f) — activated by Delegated Regulation (EU) 2022/30 and listed in Commission Implementing Decision (EU) 2025/138 — are the EN 18031-1, -2 and -3 series. EN 303 645 is referenced informatively in Annex C of each EN 18031 part as a mapping aid.

For products in scope of both consumer IoT labelling schemes (PSTI, CLS) and RED Delegated Act 2022/30, the practical path is: design to EN 303 645 + TS 103 701 → demonstrate the security mechanisms required by the relevant EN 18031 part using the same evidence. The Annex C mappings show where the same control supports both schemes.

Common mistakes

• Treating EN 303 645 as a "feature checklist" rather than outcomes. The 13 provisions are outcomes. A device that satisfies 5.1 by shipping a pre-installed unique password is just as compliant as one that requires user setup before first use — both are valid implementations of the outcome.
• Citing "EN 303 645" without a version. v2.1.1 and v3.1.3 differ in several provisions. Always pin: "EN 303 645:2020" or "EN 303 645 v2.1.1" — never bare "EN 303 645".
• Assuming EN 303 645 conformance equals RED Article 3(3) presumption of conformity. It does not. EN 303 645 is a baseline; EN 18031 is the harmonised standard listed for the RED Delegated Act. Confusing the two leads to gaps at the Module B notified body review stage.
• Implementing TS 103 701 testing without writing the ICS and IXIT first. The ICS and IXIT are not just paperwork — they pin the scope of the assessment. Lab testing without them is uncertifiable.
• Forgetting the 5.3-13 published support period. The single most overlooked provision: the support period must be visible at point of purchase. Marketing teams routinely forget this.
• Confusing 5.10 telemetry with general data collection. 5.10 is about security telemetry, not analytics. A product that collects usage data for product improvement but does not analyse it for security anomalies fails 5.10.

Using Cenitia for this work

Cenitia helps prepare evidence-linked working drafts within its supported regulatory catalogue. Confirm the product scope, actual applied standards and completed assessments, and review the result before issuance. Source-change alerts prompt a review; they do not certify conformity, automatically reissue a signed declaration or guarantee monitoring of every national rule and standard edition.

Related from the Library

• EN 18031-1 vs -2 vs -3: which part applies to your radio product — harmonised standards for RED Delegated Act 2022/30, with Annex C mapping to EN 303 645
• RED Delegated Act and EN 18031 walkthrough — how RED Article 3(3)(d), (e) and (f) become technical file evidence
• RED + CRA overlap for connected radio products — where consumer IoT obligations stack across two regulations
• Technical File template for IoT products — how to organise EN 303 645 conformance evidence in a CE technical file
• CRA Annex I explained — essential requirements — the CRA equivalent of the EN 303 645 baseline for products with digital elements

Further reading

• ETSI EN 303 645 v2.1.1 (June 2020) — original baseline PDF (free)
• ETSI EN 303 645 v3.1.3 (September 2024) — current stable version PDF (free)
• ETSI TS 103 701 v2.1.1 (May 2025) — conformance assessment specification
• ETSI press release — June 2020 standard release — official launch announcement
• ETSI press release — October 2021 TS 103 701 release — test specification announcement
• Commission Implementing Decision (EU) 2025/138 — EN 18031 OJEU listing — how EN 18031 (which maps to EN 303 645) reaches harmonised status
• BSI IT-Sicherheitskennzeichen — consumer IoT label using TS 103 701 — German national scheme reference