Fast answers to the questions product, firmware, and security teams ask most.
Grounded in ETSI EN 303 645 baseline provisions and ETSI TS 103 701 conformance assessment framing.
Structured answer sets in this page tree.
Cited legal and guidance references.
This FAQ is written for teams implementing consumer IoT security controls. It focuses on operational clarity: what you need to build, how to prove it, and what typically breaks in real products.
ETSI EN 303 645 is a security standard for consumer IoT devices and associated services. It is commonly used as a baseline for product security programs and as a reference point in procurement and assurance discussions.
Your legal obligations depend on your markets and applicable regulations. Many regulations and schemes reference ETSI-style baseline controls, but you should validate legal requirements for your specific product and jurisdictions.
Yes. Where passwords are used and in any state other than the factory default, the standard requires consumer IoT device passwords to be unique per device or defined by the user.
Where pre-installed unique per-device passwords are used, they must be generated in a way that reduces the risk of automated attacks against a class or type of device.
ETSI EN 303 645 requires a publicly available vulnerability disclosure policy with (1) contact information for reporting issues and (2) timelines for initial acknowledgement and status updates until resolution.
A strong VDP also clarifies scope (device/app/service), reporting expectations, and how coordinated vulnerability disclosure works in your organization.
ETSI EN 303 645 notes that 'timely' varies by incident, and gives conventional expectations such as completing a vulnerability process within ~90 days for software, while recognizing hardware fixes and rollout constraints may take longer.
The defensible approach is to define severity-based SLAs and then prove performance with timestamps and rollout metrics.
ETSI EN 303 645 expects software components to be securely updateable, and it requires a secure installation update mechanism for non-constrained devices. For constrained devices that cannot be updated, the standard expects transparency: publish the rationale, replacement support approach, and a defined support period, and consider isolability and hardware replaceability.
If a device cannot be patched, your vulnerability management burden increases: isolation guidance, replacement plans, and clear end-of-support communication become critical controls.
The standard expects devices to verify the authenticity and integrity of software updates, and it requires authenticity/integrity verification via a trust relationship when updates are delivered over a network interface.
In practice, this means signed updates, protected trust anchors, and robust failure handling (reject invalid updates, log safely, notify trusted parties).
ETSI EN 303 645 recommends automatic mechanisms for software updates and recommends that automatic updates and/or update notifications be enabled in the initialized state where supported, while still being configurable so users can enable/disable/postpone.
A defensible design balances user control with security outcomes and includes recovery behavior for failed automatic updates.
Strong evidence is specific and versioned: it ties each provision to a control, a verification method, and a recorded result for the exact version and configuration you ship.
ETSI TS 103 701 provides a useful assessment framing (including conceptual vs functional checks and structured declarations/information that drives test planning).
Research Copilot can take ETSI EN 303 645 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ETSI EN 303 645 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.
Start from ETSI EN 303 645 FAQ and answer scope, timing, and interpretation questions with cited outputs.
Review your current process, evidence gaps, and next steps for ETSI EN 303 645 FAQ.