Most consumer IoT compromises still start with the same handful of failures: shared default passwords, no way to report or fix vulnerabilities, unpatched firmware and secrets baked into the code, and ETSI EN 303 645 is the European baseline that names each one as a testable provision. The current version, V3.1.3 (2024-09), sets 13 groups of cyber security provisions plus data protection provisions for devices used in the home or worn on the body, together with their associated services and apps. It has become the reference point for the UK PSTI regime, national labels in Singapore and Germany, and much EU work under the Radio Equipment Directive and Cyber Resilience Act. This guide walks through the 13 provisions, separates mandatory from recommended ones, explains how conformance is assessed with ETSI TS 103 701, and shows how the standard maps to other frameworks. It is for product security engineers, compliance leads and security teams who design or source connected consumer products.
Key takeaways
- "Shall" is mandatory, "should" is a recommendation. The standard uses modal verbs, not M or R labels, and every recommendation you do not apply needs a recorded justification under provision 5.0-1.
- Three provisions carry the most weight. No universal default passwords (5.1), a published vulnerability disclosure policy (5.2-1) and a published support period (5.3-13) are the ones the UK PSTI regulations rely on for deemed compliance.
- Credentials are the core identity problem. Provision 5.4 bans hard-coded critical security parameters in software and requires per-device credentials for updates and associated services.
- Assessment is scheme neutral. ETSI TS 103 701 defines the Implementation Conformance Statement (ICS), the Implementation eXtra Information for Testing (IXIT) and test cases usable for self, second or third party assessment.
- It is a baseline, not the finish line. EU Cyber Resilience Act obligations go further, so treat EN 303 645 as the floor for consumer devices, not proof of CRA conformity.
What it is and who it applies to
EN 303 645 is a European Standard from ETSI Technical Committee CYBER, titled Cyber Security for Consumer Internet of Things: Baseline Requirements. It grew out of the 2019 Technical Specification TS 103 645 and the first EN in 2020 (V2.1.1). Version 3.1.3 was adopted on 11 September 2024. Germany's BSI lists V3.1.3 as current as of its March 2026 page update. The standard itself is voluntary; it becomes binding only when a law or scheme cites it.
- Consumer IoT device: a network-connected (and network-connectable) device that has relationships to associated services and is used by consumers, typically in the home or as a wearable.
- Examples given: connected toys and baby monitors, smoke detectors and door locks, smart cameras and TVs, wearable health trackers, home alarm systems, connected appliances, hubs and gateways, and smart home assistants.
- Out of scope: devices primarily for industrial, manufacturing or healthcare use.
- Associated services: the cloud backends and mobile apps the device relies on are part of the assessment, not optional extras.
Structure and key requirements
Provision 5.0 covers reporting implementation, clauses 5.1 to 5.13 hold the 13 cyber security provision groups (5.1 to 5.13), and clause 6 holds data protection provisions. Annex B gives a pro forma for the implementation conformance statement. Some "shall" provisions are conditional, applying unless a stated condition such as a use-case resource constraint rules them out.
| Clause | Provision group | Key mandatory (shall) provisions | Key recommendations (should) |
|---|---|---|---|
| 5.1 | No universal default passwords | 5.1-1 unique per device or user-defined; 5.1-2 pre-installed unique passwords resist automated guessing; 5.1-3 best practice cryptography for authentication; 5.1-4 easy to change authentication values; 5.1-5 brute force impracticable over network interfaces (conditional) | 5.1-2A avoid passwords for machine-to-machine authentication |
| 5.2 | Means to manage reports of vulnerabilities | 5.2-1 publish a vulnerability disclosure policy with contact information and timelines for acknowledgement and status updates | 5.2-2 act on vulnerabilities in a timely way; 5.2-3 monitor and fix through the support period |
| 5.3 | Keep software updated | 5.3-2 secure update mechanism (conditional); 5.3-3 updates simple to apply; 5.3-7 best practice cryptography; 5.3-8 timely updates; 5.3-10 verify network updates via a trust relationship; 5.3-13 publish the defined support period; 5.3-16 clearly recognisable model designation | 5.3-1 updatable components; 5.3-9 verify authenticity and integrity; 5.3-14 explain non-updatable devices |
| 5.4 | Securely store sensitive security parameters | 5.4-1 secure persistent storage; 5.4-2 tamper-resistant hard-coded identities; 5.4-3 no hard-coded critical security parameters in source code; 5.4-4 unique per-device credentials for updates and associated services | None beyond the mandatory set |
| 5.5 | Communicate securely | 5.5-1 best practice cryptography; 5.5-5 authenticate security-relevant configuration changes; 5.5-7 protect critical security parameters over remote interfaces; 5.5-8 secure key management | 5.5-2 reviewed implementations; 5.5-3 replaceable algorithms; 5.5-4 authenticated network functions; 5.5-6 encrypt parameters in transit |
| 5.6 | Minimise exposed attack surfaces | 5.6-1 disable unused interfaces; 5.6-2 minimise unauthenticated disclosure; 5.6-4A disable or protect debug interfaces | 5.6-3 physical interfaces; 5.6-5 to 5.6-9 minimal services and code, least privilege, memory protection, secure development |
| 5.7 | Ensure software integrity | None | 5.7-1 secure boot; 5.7-2 alert on unauthorised change |
| 5.8 | Ensure personal data is secure | 5.8-2 protect sensitive personal data in transit; 5.8-3 document external sensing capabilities | 5.8-1 protect personal data in transit |
| 5.9 | Make systems resilient to outages | None | Keep local function during network loss; recover cleanly after power loss |
| 5.10 | Examine system telemetry data | None | Examine telemetry for security anomalies |
| 5.11 | Make it easy to delete user data | 5.11-1 simple erasure of user data from the device | 5.11-2 to 5.11-4 deletion from services, instructions, confirmation |
| 5.12 | Make installation and maintenance easy | None | Minimal steps, secure setup guidance, configuration checks |
| 5.13 | Validate input data | 5.13-1A user interface input; 5.13-1B network interface input | None |
The pattern is clear: provisions 5.1 to 5.6 and 5.13 carry most of the mandatory requirements, while resilience, telemetry and usability (5.9, 5.10, 5.12) are recommendations. A product can conform without secure boot, but you must justify why it is not appropriate.
Identity and NHI requirements
EN 303 645 is unusually explicit about machine credentials. Each consumer device is a non-human identity, and the standard treats its secrets accordingly.
- No shared secrets across a fleet (5.4-4): credentials used for updates and for talking to associated services must be unique per device. A single API key compiled into every unit fails this provision. See the Device and IoT Identity Guide.
- No hard-coded critical security parameters (5.4-3): keys and passwords in source code or firmware images are discoverable by reverse engineering (MITRE ATT&CK T1552.001, Credentials In Files). The HPE Aruba Instant On hard-coded credentials case is a recent example of one firmware login shared by every unit.
- Prefer keys to passwords for machines (5.1-2A): device-to-cloud and device-to-hub authentication should use certificates or keys, ideally with the private key generated on the device and kept in a secure element.
- Tamper-resistant identity (5.4-2): a hard-coded unique identity, such as a device certificate, must resist physical, electrical and software tampering.
- Default and guessable passwords (5.1-1, 5.1-2): unique pre-set passwords must not follow obvious patterns such as serial numbers or incrementing counters, which is the gap exploited through Default Accounts (T1078.001) and Brute Force (T1110).
- Key lifecycle (5.5-8): generation, provisioning, rotation and revocation of device keys must follow secure key management, which needs a factory process and a backend able to revoke a single device.
- Vendor-side credentials: the associated service is in scope, so support tooling and admin accounts that reach customer devices matter. The Verkada camera breach began with admin credentials on an exposed support server, not with device firmware.
Implementation steps
- Scope the product. List the device, every app and every cloud service it uses, and which interfaces (Wi-Fi, Bluetooth, Zigbee, local web, debug) each exposes.
- Draft the ICS early. Use the Annex B pro forma and mark each provision as supported, not supported or not applicable. Record a justification for every recommendation not applied (5.0-1).
- Fix the PSTI three first. Unique passwords, a public vulnerability disclosure policy and a published support period are cheap, mandatory and legally relied on in the UK.
- Rebuild credential provisioning. Move to per-device keys or certificates injected or generated at manufacture; remove fleet-wide secrets from firmware and apps; scan release images for secrets in CI.
- Harden updates. Sign images, verify signatures on the device, protect the signing key in an HSM, and test failure and rollback behaviour so a bad update does not brick devices.
- Reduce attack surface. Disable debug interfaces and unused services in production builds; confirm with a port scan and a hardware check of UART and JTAG.
- Prepare IXIT. Document design details per claimed provision so a lab can plan grey-box tests.
- Run a self-assessment against TS 103 701, then a third-party assessment if a scheme or customer requires one. Use findings to fix shared platform components across product lines.
- Keep it current. Each major firmware release should re-check the ICS, the support period statement and the vulnerability policy links.
Evidence and assessment
ETSI TS 103 701 sets out the method. Version 1.1.1 (2021-08) was written against EN 303 645 V2.1.1; BSI lists V2.1.1 of TS 103 701 as the current version, so check that your lab assesses against the version that matches V3.1.3 of the EN.
| Assessment step | Who | What it produces |
|---|---|---|
| Identify the device under test | Supplier organisation | Model, versions, associated services in scope |
| Implementation Conformance Statement | Supplier organisation | Yes, No or N/A per provision, with justifications |
| IXIT | Supplier organisation | Design details for each claimed provision |
| ICS verification | Test laboratory | Check that no mandatory provision is "No" and N/A claims are plausible |
| Conceptual assessment | Test laboratory | Whether the documented design meets the provision |
| Functional assessment | Test laboratory | Whether the device actually behaves as documented |
| Verdict | Test laboratory | PASS, FAIL or INCONCLUSIVE per test case, group and overall |
- Not a certificate by itself: TS 103 701 does not define a certification scheme. Labels such as Singapore's Cybersecurity Labelling Scheme and Germany's IT Security Label wrap it in their own rules.
- Reuse of evidence: existing certifications can substitute for a test group if they meet the criteria in TS 103 701 clause 4.7.
- Tooling: BSI publishes a free tool, ConformXpert, that generates ICS and IXIT documentation, and its TR-03173 adds test detail where the generic standard leaves gaps.
Metrics to track
- Mandatory provision coverage: share of "shall" provisions with a PASS verdict across the product range, target 100 percent.
- Justified recommendations: share of unapplied "should" provisions with a recorded rationale, target 100 percent.
- Secrets in images: hard-coded credentials found per release scan, target zero.
- Disclosure response time: percentage of reports acknowledged within the published timescale.
- Update reach: share of active devices on the current security release 30 days after release.
On the backend, monitor failed device authentications, duplicate device identities (a sign of cloned credentials), firmware versions older than the support period allows, and telemetry anomalies in line with 5.10.
Mapping to other frameworks
Regulations and schemes that use it
- UK PSTI: the Product Security and Telecommunications Infrastructure regime has applied since 29 April 2024. Schedule 2 of the 2023 regulations treats compliance with EN 303 645 provisions 5.1-1 and 5.1-2 (passwords), 5.2-1 (reporting, with ISO/IEC 29147 as an alternative) and 5.3-13 (support period) as deemed compliance, subject to conditions.
- EU Radio Equipment Directive: the delegated act activating Articles 3(3)(d), (e) and (f) applies to wireless products placed on the EU market from 1 August 2025. Its harmonised standards are the EN 18031 series, cited in the Official Journal with restrictions in January 2025, not EN 303 645, though the technical content overlaps.
- EU Cyber Resilience Act: Regulation (EU) 2024/2847 entered into force on 10 December 2024, with vulnerability reporting obligations from 11 September 2026 and main obligations from 11 December 2027. Its essential requirements are broader than EN 303 645, and ETSI is drafting CRA product standards. See the EU Cyber Resilience Act Guide.
- Labels: Singapore's CLS Tier 1 is based on EN 303 645 and recognises PSTI-compliant products as Level 1, and BSI uses EN 303 645 as the underlying standard for several consumer IoT categories of Germany's IT Security Label.
- US Cyber Trust Mark: based on NISTIR 8425 rather than EN 303 645, but the overlap is large. See the US Cyber Trust Mark Guide.
Control mapping
| EN 303 645 | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | NISTIR 8425 |
|---|---|---|---|
| 5.1 No universal default passwords | PR.AA-01 | IA-5 | Interface Access Control |
| 5.2 Vulnerability reports | ID.RA-08 | RA-5 | Information and Query Reception |
| 5.3 Software updates | PR.PS-02 | SI-2 | Software Update |
| 5.4 Sensitive security parameters | PR.AA-01 | IA-5, SC-13 | Data Protection |
| 5.5 Communicate securely | PR.DS-02 | SC-8, SC-13 | Data Protection |
| 5.6 Minimise attack surface | PR.PS-01 | CM-7 | Interface Access Control |
| 5.7 Software integrity | PR.PS-02 | SI-7 | Software Update |
| 5.10 Telemetry | Not mapped here | Not mapped here | Cybersecurity State Awareness |
| 5.13 Validate input | Not mapped here | SA-11 | Not covered |
Choosing a route
Selling only into the UK, PSTI compliance through the three deemed-compliance provisions is the legal minimum, but full EN 303 645 conformance is cheap insurance for retail buyers. Selling into the EU, design to EN 18031 for RED now and plan for the CRA, using EN 303 645 evidence as a starting point. Small manufacturers should self-assess with TS 103 701 and the BSI tooling; large manufacturers with shared platforms get more from one third-party assessment of the platform reused across models.
Common pitfalls
- Unique but predictable passwords. Deriving the password from the MAC address or serial number meets "unique" but fails 5.1-2.
- Ignoring the app and cloud. A hardened device paired with an app holding a fleet-wide API key fails 5.4-4.
- Unjustified "should" gaps. Skipping secure boot is allowed; skipping it without a recorded rationale is a nonconformance with 5.0-1.
- Debug ports left open in production. UART shells and JTAG enabled on retail units defeat 5.6-4A.
- Support period nobody owns. The date is published once and never revisited, so devices keep selling after support has ended.
- Assuming EN 303 645 means CRA ready. CRA adds vulnerability handling, documentation and conformity assessment duties beyond this baseline.
Practitioner checklist
- Confirm you are designing and assessing against EN 303 645 V3.1.3 or later, and the matching TS 103 701 version.
- Complete the ICS for every product, with justifications for each unapplied recommendation.
- Eliminate universal default passwords and predictable per-device passwords.
- Publish a vulnerability disclosure policy with acknowledgement and status update timescales.
- Publish the defined support period in plain language at point of sale.
- Provision unique per-device keys for updates and cloud services; scan every release for hard-coded secrets.
- Sign and verify updates; hold signing keys in an HSM.
- Disable debug interfaces and unused services on production units.
- Give users a simple way to erase their data from the device.
- Map evidence once to PSTI, RED and CRA requirements to avoid duplicate work.
Standards and references
- ETSI: EN 303 645 V3.1.3, Cyber Security for Consumer Internet of Things: Baseline Requirements
- ETSI: TS 103 701, Conformance Assessment of Baseline Requirements
- UK legislation: Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 2
- GOV.UK: The UK Product Security and Telecommunications Infrastructure (PSTI) product security regime
- European Commission: Cyber Resilience Act
- BSI: Consumer IoT standards and conformance assessment
- Cyber Security Agency of Singapore: Cybersecurity Labelling Scheme for manufacturers
- NIST: IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products
Related NHI Mgmt Group resources: IoT Security Guide · Device and IoT Identity Guide · US Cyber Trust Mark Guide · EU Cyber Resilience Act Guide