ETSI EN 303 645 — Consumer IoT security
Apply a practical baseline for consumer connected products, covering credentials, vulnerability disclosure, updates, data protection and resilient operation.
After this module, you should be able to:
- Explain the baseline and its outcome-focused provisions
- Translate provisions into product and service requirements
- Plan updates and vulnerability disclosure across the support period
- Recognise implementation and assessment evidence
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-110. Consider the consumer device together with its app and associated services.
The standard establishes a practical security baseline.
ETSI EN 303 645 defines high-level cybersecurity provisions for consumer Internet of Things products and associated services. It focuses on common, high-impact weaknesses and is intended to be technology-neutral.
Its provisions cover areas such as unique credentials, vulnerability reporting, software updates, secure storage and communication, attack-surface reduction, software integrity, personal data, resilience and user-facing installation or deletion. Product context still determines the detailed controls.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Credentials | Are passwords and secrets unique, protected and changeable where needed? | Provisioning and credential records |
| Vulnerability handling | Can researchers report issues and can the organisation act? | Disclosure policy and response process |
| Updates | Are updates timely, authorised, integrity-protected and recoverable? | Update architecture and support policy |
| Attack surface | Are interfaces, privileges and exposed services minimised? | Service inventory and hardening evidence |
| Personal data | Is data protected, transparent and erasable as required? | Data map, controls and user guidance |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Define the consumer IoT product, associated services, users and support period
- 2. Map each applicable provision to a product requirement or justified rationale
- 3. Design unique identity, secure defaults and least-privilege interfaces
- 4. Implement vulnerability intake and secure, recoverable update capability
- 5. Test exposed services, credentials, data flows, reset and deletion behaviour
- 6. Publish support and security information that users can understand
Worked application: connected thermostat
Each thermostat receives a unique device identity during controlled provisioning. The service authenticates the device and user, the update package is authorised and recoverable, unused local services are disabled, and factory reset removes personal association. The manufacturer publishes a reporting route and support period.
Build evidence that explains the reasoning.
Provision, product interpretation and rationale.
Testable controls across device, app and services.
Unique identities, secret handling and factory controls.
Interface, credential, update and data-deletion tests.
Public reporting route, triage and remediation flow.
Update commitment and end-of-support communication.
Common failure patterns
Apps, APIs and provisioning services escape assessment.
One disclosure compromises the installed fleet.
Signature exists but interruption and rollback are not handled.
Users cannot make an informed security decision.
Use the baseline to examine the complete ownership journey
ETSI EN 303 645 provides a consumer-IoT security baseline. Topics include avoiding universal default passwords, receiving vulnerability reports, maintaining software, protecting security parameters, secure communication, reducing attack exposure and protecting personal data. The published V3.1.3 text is linked below; apply the controlled edition relevant to your project.
A practical review should follow the user journey from initial setup to resale or disposal. Decide how a new owner gains legitimate control, how the device binds to an account and how the previous owner’s access is removed. Factory reset, account unlinking and removal of cloud-held information are related but distinct operations.
Define what the device must still do without its associated service. A cloud outage can affect control, notifications and access even when the embedded hardware remains healthy. Make degraded behaviour and restoration understandable to the user.
Translate baseline topics into product-specific acceptance
Do not stop at a checklist entry saying that passwords are unique. Verify provisioning, change, reset and recovery. A unique printed credential can still be exposed through a predictable derivation or retained after ownership transfer. Evaluate the actual authority it provides.
For updates, establish supported components, installation conditions, failure handling and the user information needed to act. Avoid a process that requires the user to disable a protection without understanding the consequence. Keep the declared support arrangement consistent with the technical ability to deliver fixes.
Minimise exposed services and test input handling. A service left active only for factory diagnostics may remain reachable in the home. Review local radio, physical ports, application APIs and associated services as one attack surface.
| Journey stage | Illustrative verification |
|---|---|
| First setup | An unauthorised nearby user cannot claim the device after legitimate binding. |
| Daily use | Account permissions and input limits are enforced at the point of effect. |
| Update | Authenticity, compatibility and interruption handling are demonstrated. |
| Ownership transfer | Old credentials, access and relevant personal data are handled as specified. |
| Service outage | The device presents and maintains its defined local behaviour. |
Keep a baseline claim within its scope
A consumer-IoT baseline is not a complete safety case, a universal cybersecurity certificate or automatic proof of compliance with every applicable law. Establish the product’s market obligations and other relevant engineering requirements separately.
Use the baseline to expose missing operational work: vulnerability contact, response ownership, support communication and a usable recovery path. Security controls that exist in firmware but cannot be operated by users or support staff may fail to deliver their intended protection.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Design a safe ownership transfer for a smart controller
A household controller stores a Wi-Fi credential, a cloud account binding, activity history and a device identity. Pressing Factory Reset currently clears only local preferences.
- Specify which information and authorities must change during ownership transfer.
- Distinguish retained device identity from old owner access.
- Define tests covering offline reset and later reconnection.
Show the worked answer
Separate device identity needed for legitimate service from credentials and bindings that authorise the old owner. Define deletion or reset of relevant local secrets and personal information, account unlinking and treatment of associated-service data according to the product requirements. Clearing preferences alone does not revoke remote access.
Test reset while offline, setup by a new owner and later reconnection. Confirm that the old account cannot regain control and that queued commands are not replayed. If some remote action cannot complete offline, provide an explicit pending state and a reliable completion procedure. Verify that recovery remains usable without reintroducing universal or retained owner credentials.
Review criteria
- Local data and remote authority are both addressed.
- Device identity and owner credentials are distinguished.
- Offline and reconnection states cannot restore old access.
Check your understanding
Is factory reset always the same as account unlinking?
No. Local state, remote bindings and service-held data may need separate coordinated actions.
Does the baseline establish physical safety?
No. It supports security practice within its scope; physical hazards and other product obligations require their own analysis and evidence.
Further learning
- ETSI EN 303 645 V3.1.3 — Consumer IoT security baselinePublisher source supporting this module’s framework discussion.
- ETSI · Consumer IoT securityOfficial ETSI resources for the consumer IoT security baseline.
- TEA-204 · Application and connectivity engineersEnd-to-end identity, command and compatibility concerns.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.