SIST EN 303 645 V3.1.3:2024
(Main)CYBER - Cyber Security for Consumer Internet of Things: Baseline Requirements
CYBER - Cyber Security for Consumer Internet of Things: Baseline Requirements
The present document specifies high-level security and data protection provisions for consumer IoT devices that are
connected to network infrastructure (such as the Internet or home network) and their interactions with associated
services. A non-exhaustive list of examples of consumer IoT devices includes:
• connected children's toys and baby monitors;
• connected smoke detectors, door locks and window sensors;
• IoT gateways, base stations and hubs to which multiple devices connect;
• smart cameras, smart speakers and smart Televisions together with their remote controls;
• wearable health trackers;
• connected home automation and alarm systems, especially their gateways and hubs;
• connected appliances, such as washing machines and fridges; and
• smart home assistants.
Moreover, the present document addresses security considerations specific to constraints in device resources.
EXAMPLE: Typical device resources that might constrain the security capabilities are energy supply,
communication bandwidth, processing power or (non-)volatile memory capacity.
The present document provides basic guidance through examples and explanatory text for organizations involved in the
development and manufacturing of consumer IoT on how to implement those provisions. Table B.1 provides a schema
for the reader to give information about the implementation of the provisions.
Devices that are not consumer IoT devices, for example those that are primarily intended to be used in manufacturing,
healthcare or other industrial applications, are not in scope of the present document.
The present document has been developed primarily to help protect consumers, however, other users of consumer IoT
equally benefit from the implementation of the provisions set out here.
Annex A (informative) of the present document has been included to provide context to clauses 4, 5 and 6 (normative).
Annex A contains examples of device and reference architectures and an example model of device states including data
storage for each state.
CYBER - Kibernetska varnost za uporabniški internet stvari: osnovne zahteve
Ta dokument vsebuje določbe glede varnosti na visoki ravni in zaščite podatkov za uporabniške naprave v internetu stvari (IoT), ki so povezane z omrežno infrastrukturo (kot je internet ali domače omrežje), ter določa njihove interakcije s povezanimi storitvami. Nepopoln seznam primerov uporabniških naprav v internetu stvari vključuje:
• povezane igrače za otroke in otroške varuške;
• povezane detektorje dima, vratne ključavnice in senzorje za okna;
• internetne prehode, bazne postaje in vozlišča, s katerimi je povezanih več naprav;
• pametne kamere, zvočnike in televizorje ter njihove daljinske upravljalnike;
• nosljive naprave za spremljanje zdravja;
• povezane sisteme za avtomatizacijo doma in alarmne sisteme, zlasti njihove prehode in vozlišča;
• povezane naprave, kot so pralni stroji in hladilniki; ter
• pomočnike za pametne domove.
Ta dokument obravnava tudi varnostne vidike v zvezi z omejitvami virov naprav.
PRIMER: Tipični viri naprav, ki lahko omejijo varnostno zmogljivost, so oskrba z energijo, komunikacijska pasovna širina, procesorska moč ali zmogljivost (ne)obstojnega pomnilnika.
Ta dokument podaja osnovna navodila v zvezi z izvajanjem teh določb, s primeri in razlagami za organizacije, ki se ukvarjajo z razvojem in proizvodnjo uporabniškega interneta stvari. V preglednici B.1 je shema, ki bralcu zagotavlja informacije o izvajanju določb.
Naprave, ki niso uporabniške naprave v internetu stvari (na primer tiste, ki se uporabljajo predvsem v proizvodnji, zdravstvu ali za druge industrijske namene), ne spadajo na področje uporabe tega dokumenta.
Ta dokument je bil razvit predvsem za zaščito potrošnikov, vendar imajo od izvajanja tukaj navedenih določb enako korist tudi drugi uporabniki uporabniškega interneta stvari.
Dodatek A (informativni) k temu dokumentu je bil vključen za zagotavljanje konteksta za točke 4, 5 in 6 (normativne).
Dodatek A vsebuje primere arhitektur za naprave in referenčnih arhitektur ter modela stanj naprav, vključno s shranjevanjem podatkov za posamezno stanje.
General Information
Standards Content (Sample)
Draft ETSI EN 303 645 V3.1.2 (2024-06)
EUROPEAN STANDARD
CYBER;
Cyber Security for Consumer Internet of Things:
Baseline Requirements
2 Draft ETSI EN 303 645 V3.1.2 (2024-06)
Reference
REN/CYBER-00127
Keywords
cybersecurity, IoT, privacy
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2024.
All rights reserved.
ETSI
3 Draft ETSI EN 303 645 V3.1.2 (2024-06)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 11
3.3 Abbreviations . 11
4 Implementation of the standard . 12
5 Cyber security provisions for consumer IoT . 12
5.0 Reporting implementation . 12
5.1 No universal default passwords . 13
5.2 Implement a means to manage reports of vulnerabilities . 14
5.3 Keep software updated . 15
5.4 Securely store sensitive security parameters . 19
5.5 Communicate securely . 20
5.6 Minimize exposed attack surfaces . 22
5.7 Ensure software integrity . 23
5.8 Ensure that personal data is secure . 24
5.9 Make systems resilient to outages . 24
5.10 Examine system telemetry data . 25
5.11 Make it easy for users to delete user data . 25
5.12 Make installation and maintenance of devices easy . 26
5.13 Validate input data. 27
6 Data protection provisions for consumer IoT . 27
Annex A (informative): Basic concepts and models . 29
A.1 Architecture . 29
A.2 Device states . 31
A.3 Interfaces . 33
Annex B (informative): Implementation conformance statement pro forma . 35
Annex C (informative): Change history . 39
History . 40
ETSI
4 Draft ETSI EN 303 645 V3.1.2 (2024-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association. ®
BLUETOOTH is a trademark registered and owned by Bluetooth SIG, Inc.
Foreword
This draft European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER), and is
now submitted for the combined Public Enquiry and Vote phase of the ETSI EN Approval Procedure.
Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 6 months after doa
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
5 Draft ETSI EN 303 645 V3.1.2 (2024-06)
Introduction
As more devices in the home connect to the Internet, the cyber security and data protection of the Internet of Things
(IoT) becomes a growing concern. People entrust their personal data to an increasing number of online devices and
services. Products and appliances that have traditionally been offline are now connected and need to be designed to
withstand cyber threats.
The present document brings together widely considered good practices in security for Internet-connected consumer
devices in a set of high-level outcome-focused provisions. The objective of the present document is to support all
parties involved in the development and manufacturing of consumer IoT with guidance on securing their products.
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security and data protection solutions appropriate for their products.
The present document is not intended to solve all security, data protection and privacy challenges associated with
consumer IoT. It also does not focus on protecting against attacks that are prolonged/sophisticated or that require
sustained physical access to the device. Rather, the focus is on the technical controls and organizational policies that
matter most in addressing the most significant and widespread security shortcomings. Overall, a baseline level of
security and data protection is considered; this is intended to protect against elementary attacks on fundamental design
weaknesses (such as the use of easily guessable passwords).
The present document provides a set of baseline provisions applicable to all consumer IoT devices. It is intended to be
complemented by other standards defining more specific provisions and fully testable and/or verifiable requirements for
specific devices which, together with the present document, will facilitate the development of assurance schemes.
A clause in the present document in some cases begins with general information about the context of the following
provisions. A provision is followed by explanatory text describing, where appropriate, the intent of the provision and
how the provision might be implemented. Further information on implementation examples is given in ETSI
TR 103 621 [i.31].
Many consumer IoT devices and their associated services process and store personal data, the present document can
help in ensuring that these are compliant with the General Data Protection Regulation (GDPR) [i.7]. Security by design
is an important principle that is endorsed by the present document.
ETSI TS 103 701 [i.19] provides guidance on how to assess and assure IoT products against provisions within the
present document.
The provisions in the present document have been developed following a review of published standards,
recommendations and guidance on IoT security and privacy, including: ETSI TR 103 305-3 [i.1], ETSI
TR 103 309 [i.2], ENISA Baseline Security Recommendations [i.8], UK Department for Digital, Culture, Media and
Sport (DCMS) Secure by Design Report [i.9], IoT Security Foundation Compliance Framework [i.10], GSMA IoT
Security Guidelines and Assessment [i.11], ETSI TR 103 533 [i.12], DIN SPEC 27072 [i.20] and OWASP Internet of
Things [i.23].
NOTE: Mappings of the landscape of IoT security standards, recommendations and guidance are available in
ENISA Baseline Security Recommendations for IoT - Interactive Tool [i.15] and in Copper Horse
Mapping Security & Privacy in the Internet of Things [i.14].
As consumer IoT products become increasingly secure, it is envisioned that future revisions of the present document
will mandate provisions that are currently recommendations in the present document.
ETSI
6 Draft ETSI EN 303 645 V3.1.2 (2024-06)
1 Scope
The present document specifies high-level security and data protection provisions for consumer IoT devices that are
connected to network infrastructure (such as the Internet or home network) and their interactions with associated
services. A non-exhaustive list of examples of consumer IoT devices includes:
• connected children's toys and baby monitors;
• connected smoke detectors, door locks and window sensors;
• IoT gateways, base stations and hubs to which multiple devices connect;
• smart cameras, smart speakers and smart TVs together with their remote controls;
• wearable health trackers;
• connected home automation and alarm systems, especially their gateways and hubs;
• connected appliances, such as washing machines and fridges; and
• smart home assistants.
Moreover, the present document addresses security considerations specific to constraints in device resources.
EXAMPLE: Typical device resources that might constrain the security capabilities are energy supply,
communication bandwidth, processing power or (non-)volatile memory capacity.
The present document provides basic guidance through examples and explanatory text for organizations involved in the
development and manufacturing of consumer IoT on how to implement those provisions. Table B.1 provides a schema
for the reader to give information about the implementation of the provisions.
Devices that are not consumer IoT devices, for example those that are primarily intended to be used in manufacturing,
healthcare or other industrial applications, are not in scope of the present document.
The present document has been developed primarily to help protect consumers, however, other users of consumer IoT
equally benefit from the implementation of the provisions set out here.
Annex A (informative) of the present document has been included to provide context to clauses 4, 5 and 6 (normative).
Annex A contains examples of device and reference architectures and an example model of device states including data
storage for each state.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
ETSI
7 Draft ETSI EN 303 645 V3.1.2 (2024-06)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 305-3: "Cyber Security (CYBER); Critical Security Controls for Effective Cyber
Defence; Part 3: Internet of Things Sector".
[i.2] ETSI TR 103 309: "CYBER; Secure by Default - platform security technology".
[i.3] NIST Special Publication 800-63B: "Digital Identity Guidelines - Authentication and Lifecycle
Management".
[i.4] ISO/IEC 29147: "Information technology - Security techniques - Vulnerability Disclosure".
[i.5] OASIS: "CSAF Common Vulnerability Reporting Framework (CVRF)".
[i.6] ETSI TR 103 331: "Cyber Security (CYBER); Structured threat information sharing".
[i.7] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).
[i.8] ENISA: "Baseline Security Recommendations for IoT in the context of Critical Information
Infrastructures", November 2017, ISBN: 978-92-9204-236-3, doi: 10.2824/03228.
[i.9] UK Department for Digital, Culture, Media and Sport: "Secure by Design: Improving the cyber
security of consumer Internet of Things Report", March 2018.
[i.10] IoT Security Foundation: "IoT Security Assurance Framework", Release 3.0, November 2021.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice 2016/C 272/01: "The "Blue Guide" on the implementation of EU products
rules 2016" (Text with EEA relevance).
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
[i.16] IoT Security Foundation: "Understanding the Contemporary Use of Vulnerability Disclosure in
Consumer Internet of Things Product Companies".
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks". ®
[i.18] W3C : "Web of Things at W3C".
[i.19] ETSI TS 103 701: "CYBER; Cyber Security for Consumer Internet of Things: Conformance
Assessment of Baseline Requirements".
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA™: "Coordinated Vulnerability Disclosure (CVD) Programme".
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
ETSI
8 Draft ETSI EN 303 645 V3.1.2 (2024-06)
[i.24] IEEE 802.15.4-2015™/Cor 1-2018: "IEEE Standard for Low-Rate Wireless Networks,
Corrigendum 1".
[i.25] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics".
[i.26] GSMA™: "SGP.22 Technical Specification v2.2.1".
[i.27] ISO/IEC 27005:2022: "Information technology - Security techniques - Information security risk
management". ®
[i.28] Microsoft Corporation: "The STRIDE Threat Model".
[i.29] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; 5G; Vocabulary for 3GPP Specifications
(3GPP TR 21.905)".
[i.30] ETSI TR 103 838: "Cyber Security; Guide to Coordinated Vulnerability Disclosure".
[i.31] ETSI TR 103 621: " Guide to Cyber Security for Consumer Internet of Things".
[i.32] FIRST: "Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure".
[i.33] ISO/IEC TR 5895: "Cybersecurity - Multi-party coordinated vulnerability disclosure and
handling".
[i.34] ISO/IEC 16500-6:1999: "Information technology Generic digital audio-visual systems".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
administrator: user who has the highest-privilege level possible for a user of the device, which can mean they are able
to change any configuration related to the intended functionality
associated services: digital services that, together with the device, are part of the overall consumer IoT product and that
are typically required to provide the product's intended functionality
EXAMPLE 1: Associated services can include mobile applications, cloud computing/storage and third party
Application Programming Interfaces (APIs).
EXAMPLE 2: A device transmits telemetry data to a third-party service chosen by the device manufacturer. This
service is an associated service.
authentication mechanism: method used to prove the authenticity of an entity
NOTE: An "entity" can be either a user or machine.
EXAMPLE: An authentication mechanism can be the requesting of a password, scanning a QR code, or use of a
biometric fingerprint scanner.
authentication value: individual value of an attribute used by an authentication mechanism
EXAMPLE: When the authentication mechanism is to request a password, the authentication value can be a
character string. When the authentication mechanism is a biometric fingerprint recognition, the
authentication value can be the index fingerprint of the left hand.
best practice: measures that have been shown to provide appropriate security for the corresponding use case
NOTE 1: Appropriate security for the corresponding use case also considers properties of the technology, operating
environment and risk.
ETSI
9 Draft ETSI EN 303 645 V3.1.2 (2024-06)
NOTE 2: Multiple organizations, such as SDOs and public authorities, maintain guides and catalogues of measures
that can be used to identify best practice.
EXAMPLE: Applying a security configuration for a specific functionality that takes into account common
attacks and is endorsed by multiple organizations such as SDOs and public authorities.
best practice cryptography: cryptography that is suitable for the corresponding use case and has no indications of a
feasible attack with current readily available techniques
NOTE 1: This does not refer only to the cryptographic primitives used, but also implementation, key generation and
handling of keys.
NOTE 2: Multiple organizations, such as SDOs and public authorities, maintain guides and catalogues of
cryptographic methods that can be used.
EXAMPLE: The device manufacturer uses a communication protocol and cryptographic library provided with
the IoT platform and where that library and protocol have been assessed against feasible attacks,
such as replay.
consumer: natural person who is acting for purposes that are outside her/his trade, business, craft or profession
NOTE: Organizations, including businesses of any size, use consumer IoT. For example, Smart TVs are
frequently deployed in meeting rooms, and home security kits can protect the premises of small
businesses.
consumer IoT device: network-connected (and network-connectable) device that has relationships to associated
services and are used by the consumer typically in the home or as electronic wearables
NOTE 1: Consumer IoT devices are commonly also used in business contexts. These devices remain classified as
consumer IoT devices.
NOTE 2: Consumer IoT devices are often available for the consumer to purchase in retail environments. Consumer
IoT devices can also be commissioned and/or installed professionally.
critical security parameter: security-related confidential information whose disclosure or modification can
compromise the security of the device
EXAMPLE: Secret cryptographic keys, authentication values such as passwords, PINs, private components of
certificates.
debug interface: physical interface used by the manufacturer to communicate with the device during development or to
perform triage of issues with the device and that is not used as part of the consumer-facing functionality
EXAMPLE: Test points, UART, SWD, JTAG.
defined support period: minimum length of time, expressed as a period or by an end-date, for which a manufacturer
will provide security updates
NOTE: This definition focuses on security aspects and not other aspects related to product support such as
warranty.
device manufacturer: entity that creates an assembled final consumer IoT product, which is likely to contain the
products and components of many other suppliers
factory default: state of the device after factory reset or after final production/assembly
NOTE: This includes the physical device and software (including firmware) that is present on it after assembly.
initialization: process that activates the network connectivity of the device for operation and optionally sets
authentication features for a user or for network access
initialized state: state of the device after initialization
IoT product: consumer IoT device and its associated services
ETSI
10 Draft ETSI EN 303 645 V3.1.2 (2024-06)
isolable: able to be removed from the network it is connected to, where any functionality loss caused is related only to
that connectivity and not to its main function; alternatively, able to be placed in a self-contained environment with other
devices if and only if the integrity of devices within that environment can be ensured
EXAMPLE: A Smart Fridge has a touchscreen-based interface that is network-connected. This interface can be
removed without stopping the fridge from keeping the contents chilled.
logical interface: virtual interface used to communicate with the device at a logical layer
NOTE 1: Typically, the semantic, syntactic, and symbolic attributes of information flows for logical interfaces are
specified. The are alternative definitions for logical interfaces e.g. in ISO/IEC 16500-6:1999 [i.34] that
utilize this property.
NOTE 2: A logical interface may utilize a network interface to exchange information with remote endpoints.
manufacturer: relevant economic operator in the supply chain (including the device manufacturer)
NOTE: This definition acknowledges the variety of actors involved in the consumer IoT ecosystem and the
complex ways by which they can share responsibilities. Beyond the device manufacturer, such entities
can also be, for example and depending on a specific case at hand: importers, distributors, integrators,
component and platform providers, software providers, IT and telecommunications service providers,
managed service providers and providers of associated services.
network interface: physical interface that can be used to access the functionality of consumer IoT via a network
owner: user who owns or who purchased the device
personal data: any information relating to an identified or identifiable natural person
NOTE: This term is used to align with well-known terminology but has no legal meaning within the present
document.
physical interface: physical port or air interface (such as radio, audio or optical) used to communicate with the device
at the physical layer
EXAMPLE: Radios, ethernet ports, serial interfaces such as USB, and those used for debugging.
public security parameter: security-related public information whose modification can compromise the security of the
device
EXAMPLE 1: A public key to verify the authenticity/integrity of software updates.
EXAMPLE 2: Public components of certificates.
remotely accessible: intended to be accessible from outside the local network
security module: set of hardware, software, and/or firmware that implements security functions
EXAMPLE: A device contains a hardware root of trust, a cryptographic software library that operates within a
trusted execution environment, and software within the operating system that enforces security
such as user separation and the update mechanism. These all make up the security module.
security update: software update that addresses security vulnerabilities either discovered by or reported to the
manufacturer
NOTE: Software updates can be purely security updates if the severity of the vulnerability requires a higher
priority fix.
sensitive security parameters: critical security parameters and public security parameters
software service: software component of a device that is used to support functionality
EXAMPLE: A runtime for the programming language used within the device software or a daemon that
exposes an API used by the device software, e.g. a cryptographic module's API.
ETSI
11 Draft ETSI EN 303 645 V3.1.2 (2024-06)
telemetry data: data from a device that provide information related to the usage of that device which could help the
manufacturer to identify security-related issues
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
NOTE 1: Telemetry data cover usage data, performance data, but also sensor data which facilitate the monitoring of
the device's physical and environmental conditions. Therefore, telemetry data do not only help to identify
security-related issues, but also help to improve the device's performance and user experience.
NOTE 2: Depending on the content of the telemetry data, telemetry data such as usage data may be considered as
personal data.
unique per device: unique for each individual device of a given product class or type
user: natural person or organization
user interface: user facing interface of the consumer IoT device
EXAMPLE: Buttons, screens, speaker, audio/video recorder as part of the consumer IoT device or user facing
logical interfaces such as frontends of services provided by the consumer IoT device.
vulnerability management process: course of action in which an organization addresses and remediates a disclosed
vulnerability
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
ASLR Address Space Layout Randomization
CVD Coordinated Vulnerability Disclosure
CVRF Common Vulnerability Reporting Framework
DDoS Distributed Denial of Service
DSC Dedicated Security Components
ENISA European Union Agency for Network and Information Security
EU European Union
GDPR General Data Protection Regulation
GSM Global System for Mobile communications
GSMA GSM Association
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
IP Internet Protocol
ISO International Organization for Standardization
JTAG Joint Test Action Group
LAN Local Area Network
LoRaWAN Long Range Wide Area Network
MAC Media Access Control
MPCVD Multi-Party Coordinated Vulnerability Disclosure
NIST National Institute of Standards and Technology
NX No eXecute
OTP One-Time Password
OWASP Open Web Application Security Project
QR Quick Response
SBOM Software Bill of Materials
SDO Standards Development Organization
SE Secure Elements
SSID Service Set IDentifier
ETSI
12 Draft ETSI EN 303 645 V3.1.2 (2024-06)
STRIDE Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of
privilege
SWD Serial Wire Debug
TEE Trusted Execution Environment
TS Technical Specification
UART Universal Asynchronous Receiver-Transmitter
UI User Interface
UK United Kingdom
USB Universal Serial Bus
WAN Wide Area Network
4 Implementation of the standard
The implementation of provisions in the present document is informed by risk assessment and threat modelling (such as
ISO/IEC 27005:2022 [i.27] and STRIDE Threat Model [i.28]) and data protection and privacy impact assessments; that
are performed by the device manufacturer and/or other relevant entities and are out of scope of the present document.
For certain use cases and following risk assessment, it can be appropriate to apply additional provisions as well as those
contained within the present document. In all cases, security, data protection and privacy by design and by default
should be used to inform the product development process, following risk assessment, but that is out of scope of the
present document.
The present document sets a security and data protection baseline; however, due to the broad landscape of consumer
IoT it is recognized that the applicability of provisions is dependent on each device. The present document provides a
degree of flexibility through the use of non-mandatory "should" provisions (recommendations).
The present document defines the security requirements for the device, it does not define a testing or certification
method to assess the requirements against. Some methods of fulfilling the requirements in the present document can
impact testing and certification making it very difficult, or even impossible, to demonstrate compliance in certain test
regimes.
Testing and certification involving third party assessment is likely to require documentation, including architectural
design documentation, security requirements capture and analysis, threat models and environmental assumptions, policy
documentation for lifecycle management (including supply chain management), assessment certificates for any
components that are used to implement functionality required in the present document. These documentation
requirements will be defined by the testing regime and are out of scope of the present document. A way to assess
conformance to the present document is specified in ETSI TS 103 701 [i.19].
5 Cyber security provisions for consumer IoT
5.0 Reporting implementation
Provision 5.0-1 A justification shall be recorded for each recommendation in the present document that is considered to
be not applicable for or not fulfilled by the consumer IoT device.
It is recommended that the manufacturer conducts a threat modelling to identify, analyse and mitigate threats to the
device.
Table B.1 provides a schema to record these justifications in a structured manner. This is to allow other stakeholders
(e.g. assurance assessors, members of the supply chain, security researchers or retailers) to determine whether
provisions have been applied correctly and appropriately.
EXAMPLE 1: The manufacturer publishes a completed version of table B.1 alongside the product description on
their website.
EXAMPLE 2: The manufacturer completes table B.1 for internal record keeping. Sometime later, an external
assurance organization assesses a product against the present document and requests information
relating to the product's security design. The manufacturer can easily provide this information as it
is contained within table B.1.
ETSI
13 Draft ETSI EN 303 645 V3.1.2 (2024-06)
Cases where a provision is not applicable or not fulfilled by the consumer IoT device can include:
• when the use case of a device determines constraints in resources that prevent the implementation of certain
security measures or certain security measures are not appropriate to the identified risk (security or privacy);
• where the functionality described in the provision is not included (e.g. a device that only presents data without
requiring authentication);
• when the use case for the device requires compliance with additional industry or regulatory requirements that
preclude compliance with the provision.
EXAMPLE 3: The consumer IoT device and associated service processes payments and is therefore required to
comply with the payment card industry specifications and for transaction processing and industry
and regulatory requirements for fraud monitoring. Fraud monitoring can conflict with
provision 5.11-2 that recommends allowing users to be able to delete all personal data on the
associated service, potentially including the records necessary to detect fraudulent activity.
5.1 No universal default passwords
Provision 5.1-1 Where passwords are used to authenticate users against the device or for machine-to-machine
authentication, and in any state other than the factory default, all consumer IoT device passwords shall be unique per
device or defined by the user.
NOTE 1: There are many mechanisms used for performing authentication, and passwords are not the only
mechanism for authenticating a user to a device. However if they are used, following best practice on
passwords is encouraged according to NIST Special Publication 800-63B [i.3].
NOTE 2: Standard pairing codes are not considered as passwords used for machine-to-machine authentication.
Many consumer IoT devices are sold with universal default usernames and passwords (such as "admin, admin") for user
interfaces through to network protocols. Continued usage of universal default values has been the source of many
security issues in IoT [i.17] and the practice needs to be discontinued. The above provision can be achieved by the use
of pre-installed passwords that are unique per device and/or by requiring the user to choose a password that follows best
practice as part of initialization, or by some other method that does not use passwords.
EXAMPLE 1: During initialization a consumer IoT device generates certificates that are used to authenticate a
user to the consumer IoT device via an associated service like a mobile application.
To increase security, multi-factor authentication, such as use of a password plus OTP procedure, can be used to better
protect the consumer IoT device or an associated service. Consumer IoT device security can further be strengthened by
having unique and immutable identities.
Provision 5.1-2 Where pre-installed unique per device passwords are used to authenticate users against the device or
for machine-to-machine authentication, these shall be generated with a mechanism that reduces the risk of automated
attacks against a class or type of consumer IoT device.
EXAMPLE 2: Pre-installed passwords are sufficiently randomized.
As a counter-example, passwords with incremental counters (such as "password1", "password2" and so on) are easily
guessable. Further, using a password that is related in an obvious way to public information (sent over the air or within ®
a network), such as MAC address or Wi-Fi SSID, can allow for password retrieval using automated means.
Provision 5.1-2A Passwords should not be used for machine-to-machine authentication.
Using human-memorable passwords for machine-to-machine authentication is generally not appropriate, but pre-shared
keys can be appropriate when their use follows best practice.
Provision 5.1-3 Authentication mechanisms used to authenticate users against the consumer IoT device or used for
machine-to-machine authentication shall use best practice cryptography, appropriate to the properties of the technology,
operating environment, risk and usage.
ETSI
14 Draft ETSI EN 303 645 V3.1.2 (2024-06)
Provision 5.1-4 Where a user can authenticate against a consumer IoT device, the consumer IoT device shall provide to
the user or an administrator a simple mechanism to change the authentication value used.
EXAMPLE 3: For biometric authentication values the device manufacturer allows this change in authentication
value through retraining against a new biometric.
EXAMPLE 4: A parent in a household creates an account on the consumer IoT device for their child and selects
and manages the PIN or password that the child uses. The parent is an administrator on the
consumer IoT device and can restrict the child from changing the PIN or password.
EXAMPLE 5: To make it simple for the user to change a password, the manufacturer designs the password
change process in a way that it requires a minimal number of steps. The manufacturer explains the
process in a user manual and in a video tutorial.
An authentication mechanism used for authenticating users, whether it be a fingerprint, password or other token, needs
to have its value changeable. This is easier when this mechanism is part of the normal usage flow of the consumer IoT
device.
Provision 5.1-5 The consumer IoT device shall have a mechanism available which makes successful brute-force attacks
on authentication mechanisms via network interfaces impracticable unless the device has a resource constraint
determined by the use case that prevents the implementation.
EXAMPLE 6: A consumer IoT device has a limitation on the number of authentication attempts within a certain
time interval. It also uses increasing time intervals between attempts.
EXAMPLE 7: The client application is able to lock an account or to delay additional authentication attempts after
a limited number of failed authentication attempts.
This provision addresses attacks that perform "credential stuffing" or exhaust an entire key-space. It is important that
these types of attacks are detected by the consumer IoT device and defended against, whilst guarding against a related
threat of "resource exhaustion" and denial of service attacks.
5.2 Implement a means to manage reports of vulnerabilities
Manufacturers that provide IoT products have a duty of care to consumers and third parties who can be harmed by their
failure to have a CVD programme in place. Additionally, companies that share this information through industry bodies
can assist others who can be suffering from the same problem.
Disclosures can comprise different approaches depending on the circumstances
...
EUROPEAN STANDARD
CYBER;
Cyber Security for Consumer Internet of Things:
Baseline Requirements
2 ETSI EN 303 645 V3.1.3 (2024-09)
Reference
REN/CYBER-00127
Keywords
cybersecurity, IoT, privacy
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2024.
All rights reserved.
ETSI
3 ETSI EN 303 645 V3.1.3 (2024-09)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 11
3.3 Abbreviations . 11
4 Implementation of the standard . 12
5 Cyber security provisions for consumer IoT . 12
5.0 Reporting implementation . 12
5.1 No universal default passwords . 13
5.2 Implement a means to manage reports of vulnerabilities . 14
5.3 Keep software updated . 16
5.4 Securely store sensitive security parameters . 20
5.5 Communicate securely . 21
5.6 Minimize exposed attack surfaces . 22
5.7 Ensure software integrity . 24
5.8 Ensure that personal data is secure . 24
5.9 Make systems resilient to outages . 25
5.10 Examine system telemetry data . 25
5.11 Make it easy for users to delete user data . 25
5.12 Make installation and maintenance of devices easy . 26
5.13 Validate input data. 27
6 Data protection provisions for consumer IoT . 28
Annex A (informative): Basic concepts and models . 30
A.1 Architecture . 30
A.2 Device states . 32
A.3 Interfaces . 34
Annex B (informative): Implementation conformance statement pro forma . 36
Annex C (informative): Change history . 40
History . 41
ETSI
4 ETSI EN 303 645 V3.1.3 (2024-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association. ®
BLUETOOTH is a trademark registered and owned by Bluetooth SIG, Inc.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER).
National transposition dates
Date of adoption of this EN: 11 September 2024
Date of latest announcement of this EN (doa): 31 December 2024
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 June 2025
Date of withdrawal of any conflicting National Standard (dow): 30 June 2025
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
5 ETSI EN 303 645 V3.1.3 (2024-09)
Introduction
As more devices in the home connect to the Internet, the cyber security and data protection of the Internet of Things
(IoT) becomes a growing concern. People entrust their personal data to an increasing number of online devices and
services. Products and appliances that have traditionally been offline are now connected and need to be designed to
withstand cyber threats.
The present document brings together widely considered good practices in security for Internet-connected consumer
devices in a set of high-level outcome-focused provisions. The objective of the present document is to support all
parties involved in the development and manufacturing of consumer IoT with guidance on securing their products.
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security and data protection solutions appropriate for their products.
The present document is not intended to solve all security, data protection and privacy challenges associated with
consumer IoT. It also does not focus on protecting against attacks that are prolonged/sophisticated or that require
sustained physical access to the device. Rather, the focus is on the technical controls and organizational policies that
matter most in addressing the most significant and widespread security shortcomings. Overall, a baseline level of
security and data protection is considered; this is intended to protect against elementary attacks on fundamental design
weaknesses (such as the use of easily guessable passwords).
The present document provides a set of baseline provisions applicable to all consumer IoT devices. It is intended to be
complemented by other standards defining more specific provisions and fully testable and/or verifiable requirements for
specific devices which, together with the present document, will facilitate the development of assurance schemes.
A clause in the present document in some cases begins with general information about the context of the following
provisions. A provision is followed by explanatory text describing, where appropriate, the intent of the provision and
how the provision might be implemented. Further information on implementation examples is given in ETSI
TR 103 621 [i.31].
Many consumer IoT devices and their associated services process and store personal data, the present document can
help in ensuring that these are compliant with the General Data Protection Regulation (GDPR) [i.7]. Security by design
is an important principle that is endorsed by the present document.
ETSI TS 103 701 [i.19] provides guidance on how to assess and assure IoT products against provisions within the
present document.
The provisions in the present document have been developed following a review of published standards,
recommendations and guidance on IoT security and privacy, including: ETSI TR 103 305-3 [i.1], ETSI
TR 103 309 [i.2], ENISA Baseline Security Recommendations [i.8], UK Department for Digital, Culture, Media and
Sport (DCMS) Secure by Design Report [i.9], IoT Security Foundation Compliance Framework [i.10], GSMA IoT
Security Guidelines and Assessment [i.11], ETSI TR 103 533 [i.12], DIN SPEC 27072 [i.20] and OWASP Internet of
Things [i.23].
NOTE: Mappings of the landscape of IoT security standards, recommendations and guidance are available in
ENISA Baseline Security Recommendations for IoT - Interactive Tool [i.15] and in Copper Horse
Mapping Security & Privacy in the Internet of Things [i.14].
As consumer IoT products become increasingly secure, it is envisioned that future revisions of the present document
will mandate provisions that are currently recommendations in the present document.
ETSI
6 ETSI EN 303 645 V3.1.3 (2024-09)
1 Scope
The present document specifies high-level security and data protection provisions for consumer IoT devices that are
connected to network infrastructure (such as the Internet or home network) and their interactions with associated
services. A non-exhaustive list of examples of consumer IoT devices includes:
• connected children's toys and baby monitors;
• connected smoke detectors, door locks and window sensors;
• IoT gateways, base stations and hubs to which multiple devices connect;
• smart cameras, smart speakers and smart Televisions together with their remote controls;
• wearable health trackers;
• connected home automation and alarm systems, especially their gateways and hubs;
• connected appliances, such as washing machines and fridges; and
• smart home assistants.
Moreover, the present document addresses security considerations specific to constraints in device resources.
EXAMPLE: Typical device resources that might constrain the security capabilities are energy supply,
communication bandwidth, processing power or (non-)volatile memory capacity.
The present document provides basic guidance through examples and explanatory text for organizations involved in the
development and manufacturing of consumer IoT on how to implement those provisions. Table B.1 provides a schema
for the reader to give information about the implementation of the provisions.
Devices that are not consumer IoT devices, for example those that are primarily intended to be used in manufacturing,
healthcare or other industrial applications, are not in scope of the present document.
The present document has been developed primarily to help protect consumers, however, other users of consumer IoT
equally benefit from the implementation of the provisions set out here.
Annex A (informative) of the present document has been included to provide context to clauses 4, 5 and 6 (normative).
Annex A contains examples of device and reference architectures and an example model of device states including data
storage for each state.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
ETSI
7 ETSI EN 303 645 V3.1.3 (2024-09)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 305-3: "Cyber Security (CYBER); Critical Security Controls for Effective Cyber
Defence; Part 3: Internet of Things Sector".
[i.2] ETSI TR 103 309: "CYBER; Secure by Default - platform security technology".
[i.3] NIST Special Publication 800-63B: "Digital Identity Guidelines - Authentication and Lifecycle
Management".
[i.4] ISO/IEC 29147: "Information technology - Security techniques - Vulnerability Disclosure".
[i.5] OASIS csaf-v2.0: "Common Security Advisory Framework", version 2.0,edited by Langley Rock,
Stefan Hagen, and Thomas Schmidt, 18 November 2022 and the errata 01.
[i.6] ETSI TR 103 331: "Cyber Security (CYBER); Structured threat information sharing".
[i.7] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).
[i.8] ENISA: "Baseline Security Recommendations for IoT in the context of Critical Information
Infrastructures", November 2017, ISBN: 978-92-9204-236-3, doi: 10.2824/03228.
[i.9] UK Department for Digital, Culture, Media and Sport: "Secure by Design: Improving the cyber
security of consumer Internet of Things Report", March 2018.
[i.10] IoT Security Foundation: "IoT Security Assurance Framework", Release 3.0, November 2021.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice 2016/C 272/01: "The "Blue Guide" on the implementation of EU products
rules 2016" (Text with EEA relevance).
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
[i.16] IoT Security Foundation: "Understanding the Contemporary Use of Vulnerability Disclosure in
Consumer Internet of Things Product Companies".
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks". ®
[i.18] W3C : "Web of Things at W3C".
[i.19] ETSI TS 103 701: "CYBER; Cyber Security for Consumer Internet of Things: Conformance
Assessment of Baseline Requirements".
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA™: "Coordinated Vulnerability Disclosure (CVD) Programme".
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
ETSI
8 ETSI EN 303 645 V3.1.3 (2024-09)
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
[i.24] IEEE 802.15.4-2015™/Cor 1-2018: "IEEE Standard for Low-Rate Wireless Networks,
Corrigendum 1".
[i.25] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics".
[i.26] GSMA™: "SGP.22 Technical Specification v2.2.1".
[i.27] ISO/IEC 27005:2022: "Information technology - Security techniques - Information security risk
management". ®
[i.28] Microsoft Corporation: "The STRIDE Threat Model".
[i.29] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; 5G; Vocabulary for 3GPP Specifications
(3GPP TR 21.905)".
[i.30] ETSI TR 103 838: "Cyber Security; Guide to Coordinated Vulnerability Disclosure".
[i.31] ETSI TR 103 621: " Guide to Cyber Security for Consumer Internet of Things".
[i.32] FIRST: "Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure".
[i.33] ISO/IEC TR 5895: "Cybersecurity - Multi-party coordinated vulnerability disclosure and
handling".
[i.34] ISO/IEC 16500-6:1999: "Information technology Generic digital audio-visual systems".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
administrator: user who has the highest-privilege level possible for a user of the device, which can mean they are able
to change any configuration related to the intended functionality
associated services: digital services that, together with the device, are part of the overall consumer IoT product and that
are typically required to provide the product's intended functionality
EXAMPLE 1: Associated services can include mobile applications, cloud computing/storage and third party
Application Programming Interfaces (APIs).
EXAMPLE 2: A device transmits telemetry data to a third-party service chosen by the device manufacturer. This
service is an associated service.
authentication mechanism: method used to prove the authenticity of an entity
NOTE: An "entity" can be either a user or machine.
EXAMPLE: An authentication mechanism can be the requesting of a password, scanning a QR code, or use of a
biometric fingerprint scanner.
authentication value: individual value of an attribute used by an authentication mechanism
EXAMPLE: When the authentication mechanism is to request a password, the authentication value can be a
character string. When the authentication mechanism is a biometric fingerprint recognition, the
authentication value can be the index fingerprint of the left hand.
ETSI
9 ETSI EN 303 645 V3.1.3 (2024-09)
best practice: measures that have been shown to provide appropriate security for the corresponding use case
NOTE 1: Appropriate security for the corresponding use case also considers properties of the technology, operating
environment and risk.
NOTE 2: Multiple organizations, such as SDOs and public authorities, maintain guides and catalogues of measures
that can be used to identify best practice.
EXAMPLE: Applying a security configuration for a specific functionality that takes into account common
attacks and is endorsed by multiple organizations such as SDOs and public authorities.
best practice cryptography: cryptography that is suitable for the corresponding use case and has no indications of a
feasible attack with current readily available techniques
NOTE 1: This does not refer only to the cryptographic primitives used, but also implementation, key generation and
handling of keys.
NOTE 2: Multiple organizations, such as SDOs and public authorities, maintain guides and catalogues of
cryptographic methods that can be used.
EXAMPLE: The device manufacturer uses a communication protocol and cryptographic library provided with
the IoT platform and where that library and protocol have been assessed against feasible attacks,
such as replay.
consumer: natural person who is acting for purposes that are outside her/his trade, business, craft or profession
NOTE: Organizations, including businesses of any size, use consumer IoT. For example, Smart Televisions are
frequently deployed in meeting rooms, and home security kits can protect the premises of small
businesses.
consumer IoT device: network-connected (and network-connectable) device that has relationships to associated
services and are used by the consumer typically in the home or as electronic wearables
NOTE 1: Consumer IoT devices are commonly also used in business contexts. These devices remain classified as
consumer IoT devices.
NOTE 2: Consumer IoT devices are often available for the consumer to purchase in retail environments. Consumer
IoT devices can also be commissioned and/or installed professionally.
critical security parameter: security-related confidential information whose disclosure or modification can
compromise the security of the device
EXAMPLE: Secret cryptographic keys, authentication values such as passwords, PINs, private components of
certificates.
debug interface: physical interface used by the manufacturer to communicate with the device during development or to
perform triage of issues with the device and that is not used as part of the consumer-facing functionality
EXAMPLE: Test points, UART, SWD, JTAG.
defined support period: minimum length of time, expressed as a period or by an end-date, for which a manufacturer
will provide security updates
NOTE: This definition focuses on security aspects and not other aspects related to product support such as
warranty.
device manufacturer: entity that creates an assembled final consumer IoT product, which is likely to contain the
products and components of many other suppliers
factory default: state of the device after factory reset or after final production/assembly
NOTE: This includes the physical device and software (including firmware) that is present on it after assembly.
initialization: process that activates the network connectivity of the device for operation and optionally sets
authentication features for a user or for network access
initialized state: state of the device after initialization
ETSI
10 ETSI EN 303 645 V3.1.3 (2024-09)
IoT product: consumer IoT device and its associated services
isolable: able to be removed from the network it is connected to, where any functionality loss caused is related only to
that connectivity and not to its main function; alternatively, able to be placed in a self-contained environment with other
devices if and only if the integrity of devices within that environment can be ensured
EXAMPLE: A Smart Fridge has a touchscreen-based interface that is network-connected. This interface can be
removed without stopping the fridge from keeping the contents chilled.
logical interface: virtual interface used to communicate with the device at a logical layer
NOTE 1: Typically, the semantic, syntactic, and symbolic attributes of information flows for logical interfaces are
specified. The are alternative definitions for logical interfaces e.g. in ISO/IEC 16500-6:1999 [i.34] that
utilize this property.
NOTE 2: A logical interface may utilize a network interface to exchange information with remote endpoints.
manufacturer: relevant economic operator in the supply chain (including the device manufacturer)
NOTE: This definition acknowledges the variety of actors involved in the consumer IoT ecosystem and the
complex ways by which they can share responsibilities. Beyond the device manufacturer, such entities
can also be, for example and depending on a specific case at hand: importers, distributors, integrators,
component and platform providers, software providers, IT and telecommunications service providers,
managed service providers and providers of associated services.
network interface: physical interface that can be used to access the functionality of consumer IoT via a network
owner: user who owns or who purchased the device
personal data: any information relating to an identified or identifiable natural person
NOTE: This term is used to align with well-known terminology but has no legal meaning within the present
document.
physical interface: physical port or air interface (such as radio, audio or optical) used to communicate with the device
at the physical layer
EXAMPLE: Radios, ethernet ports, serial interfaces such as USB, and those used for debugging.
public security parameter: security-related public information whose modification can compromise the security of the
device
EXAMPLE 1: A public key to verify the authenticity/integrity of software updates.
EXAMPLE 2: Public components of certificates.
remotely accessible: intended to be accessible from outside the local network
security module: set of hardware, software, and/or firmware that implements security functions
EXAMPLE: A device contains a hardware root of trust, a cryptographic software library that operates within a
trusted execution environment, and software within the operating system that enforces security
such as user separation and the update mechanism. These all make up the security module.
security update: software update that addresses security vulnerabilities either discovered by or reported to the
manufacturer
NOTE: Software updates can be purely security updates if the severity of the vulnerability requires a higher
priority fix.
sensitive security parameters: critical security parameters and public security parameters
software service: software component of a device that is used to support functionality
EXAMPLE: A runtime for the programming language used within the device software or a daemon that
exposes an API used by the device software, e.g. a cryptographic module's API.
ETSI
11 ETSI EN 303 645 V3.1.3 (2024-09)
telemetry data: data from a device that provide information related to the usage of that device which could help the
manufacturer to identify security-related issues
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
NOTE 1: Telemetry data cover usage data, performance data, but also sensor data which facilitate the monitoring of
the device's physical and environmental conditions. Therefore, telemetry data do not only help to identify
security-related issues, but also help to improve the device's performance and user experience.
NOTE 2: Depending on the content of the telemetry data, telemetry data such as usage data may be considered as
personal data.
unique per device: unique for each individual device of a given product class or type
user: natural person or organization
user interface: user facing interface of the consumer IoT device
EXAMPLE: Buttons, screens, speaker, audio/video recorder as part of the consumer IoT device or user facing
logical interfaces such as frontends of services provided by the consumer IoT device.
vulnerability management process: course of action in which an organization addresses and remediates a disclosed
vulnerability
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
ARP Address Resolution Protocol
ASLR Address Space Layout Randomization
CVD Coordinated Vulnerability Disclosure
CSAF Common Security Advisory Framework
DDoS Distributed Denial of Service
DHCP Dynamic Host Configuration Protocol
DLNA Digital Living Network Alliance
DNS Domain Name System
DSC Dedicated Security Components
ENISA European Union Agency for Network and Information Security
EU European Union
GDPR General Data Protection Regulation
GSM Global System for Mobile communications
GSMA GSM Association
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
IP Internet Protocol
ISO International Organization for Standardization
JTAG Joint Test Action Group
LAN Local Area Network
LoRaWAN Long Range Wide Area Network
LTE Long Term Evolution
MAC Media Access Control
MMU Memory Management Unit
MPCVD Multi-Party Coordinated Vulnerability Disclosure
MPU Memory Protection Unit
ETSI
12 ETSI EN 303 645 V3.1.3 (2024-09)
NFC Near Field Communication
NIST National Institute of Standards and Technology
NTP Network Time Protocol
NX No eXecute
OTP One-Time Password
OWASP Open Web Application Security Project
QR Quick Response
RES RESet
SBOM Software Bill of Materials
SDO Standards Development Organization
SE Secure Elements
SQL Structured Query Language
SSID Service Set IDentifier
STRIDE Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of
privilege
SWD Serial Wire Debug
TEE Trusted Execution Environment
TS Technical Specification
UART Universal Asynchronous Receiver-Transmitter
UI User Interface
UICC Universal Integrated Circuit Card
UK United Kingdom
USB Universal Serial Bus
WAN Wide Area Network
WPS Wi-Fi Protected Setup
4 Implementation of the standard
The implementation of provisions in the present document is informed by risk assessment and threat modelling (such as
ISO/IEC 27005:2022 [i.27] and STRIDE Threat Model [i.28]) and data protection and privacy impact assessments; that
are performed by the device manufacturer and/or other relevant entities and are out of scope of the present document.
For certain use cases and following risk assessment, it can be appropriate to apply additional provisions as well as those
contained within the present document. In all cases, security, data protection and privacy by design and by default
should be used to inform the product development process, following risk assessment, but that is out of scope of the
present document.
The present document sets a security and data protection baseline; however, due to the broad landscape of consumer
IoT it is recognized that the applicability of provisions is dependent on each device. The present document provides a
degree of flexibility through the use of non-mandatory "should" provisions (recommendations).
The present document defines the security requirements for the device, it does not define a testing or certification
method to assess the requirements against. Some methods of fulfilling the requirements in the present document can
impact testing and certification making it very difficult, or even impossible, to demonstrate compliance in certain test
regimes.
Testing and certification involving third party assessment is likely to require documentation, including architectural
design documentation, security requirements capture and analysis, threat models and environmental assumptions, policy
documentation for lifecycle management (including supply chain management), assessment certificates for any
components that are used to implement functionality required in the present document. These documentation
requirements will be defined by the testing regime and are out of scope of the present document. A way to assess
conformance to the present document is specified in ETSI TS 103 701 [i.19].
5 Cyber security provisions for consumer IoT
5.0 Reporting implementation
Provision 5.0-1 A justification shall be recorded for each recommendation in the present document that is considered to
be not applicable for or not fulfilled by the consumer IoT device.
ETSI
13 ETSI EN 303 645 V3.1.3 (2024-09)
It is recommended that the manufacturer conducts a threat modelling to identify, analyse and mitigate threats to the
device.
Table B.1 provides a schema to record these justifications in a structured manner. This is to allow other stakeholders
(e.g. assurance assessors, members of the supply chain, security researchers or retailers) to determine whether
provisions have been applied correctly and appropriately.
EXAMPLE 1: The manufacturer publishes a completed version of table B.1 alongside the product description on
their website.
EXAMPLE 2: The manufacturer completes table B.1 for internal record keeping. Sometime later, an external
assurance organization assesses a product against the present document and requests information
relating to the product's security design. The manufacturer can easily provide this information as it
is contained within table B.1.
Cases where a provision is not applicable or not fulfilled by the consumer IoT device can include:
• when the use case of a device determines constraints in resources that prevent the implementation of certain
security measures or certain security measures are not appropriate to the identified risk (security or privacy);
• where the functionality described in the provision is not included (e.g. a device that only presents data without
requiring authentication);
• when the use case for the device requires compliance with additional industry or regulatory requirements that
preclude compliance with the provision.
EXAMPLE 3: The consumer IoT device and associated service processes payments and is therefore required to
comply with the payment card industry specifications and for transaction processing and industry
and regulatory requirements for fraud monitoring. Fraud monitoring can conflict with
provision 5.11-2 that recommends allowing users to be able to delete all personal data on the
associated service, potentially including the records necessary to detect fraudulent activity.
5.1 No universal default passwords
Provision 5.1-1 Where passwords are used to authenticate users against the device or for machine-to-machine
authentication, and in any state other than the factory default, all consumer IoT device passwords shall be unique per
device or defined by the user.
NOTE 1: There are many mechanisms used for performing authentication, and passwords are not the only
mechanism for authenticating a user to a device. However if they are used, following best practice on
passwords is encouraged according to NIST Special Publication 800-63B [i.3].
NOTE 2: Standard pairing codes are not considered as passwords used for machine-to-machine authentication.
Many consumer IoT devices are sold with universal default usernames and passwords (such as "admin, admin") for user
interfaces through to network protocols. Continued usage of universal default values has been the source of many
security issues in IoT [i.17] and the practice needs to be discontinued. The above provision can be achieved by the use
of pre-installed passwords that are unique per device and/or by requiring the user to choose a password that follows best
practice as part of initialization, or by some other method that does not use passwords.
EXAMPLE 1: During initialization a consumer IoT device generates certificates that are used to authenticate a
user to the consumer IoT device via an associated service like a mobile application.
To increase security, multi-factor authentication, such as use of a password plus OTP procedure, can be used to better
protect the consumer IoT device or an associated service. Consumer IoT device security can further be strengthened by
having unique and immutable identities.
Provision 5.1-2 Where pre-installed unique per device passwords are used to authenticate users against the device or
for machine-to-machine authentication, these shall be generated with a mechanism that reduces the risk of automated
attacks against a class or type of consumer IoT device.
EXAMPLE 2: Pre-installed passwords are sufficiently randomized.
ETSI
14 ETSI EN 303 645 V3.1.3 (2024-09)
As a counter-example, passwords with incremental counters (such as "password1", "password2" and so on) are easily
guessable. Further, using a password that is related in an obvious way to public information (sent over the air or within ®
SSID, can allow for password retrieval using automated means.
a network), such as MAC address or Wi-Fi
Provision 5.1-2A Passwords should not be used for machine-to-machine authentication.
Using human-memorable passwords for machine-to-machine authentication is generally not appropriate, but pre-shared
keys can be appropriate when their use follows best practice.
Provision 5.1-3 Authentication mechanisms used to authenticate users against the consumer IoT device or used for
machine-to-machine authentication shall use best practice cryptography, appropriate to the properties of the technology,
operating environment, risk and usage.
Provision 5.1-4 Where a user can authenticate against a consumer IoT device, the consumer IoT device shall provide to
the user or an administrator a simple mechanism to change the authentication value used.
EXAMPLE 3: For biometric authentication values the device manufacturer allows this change in authentication
value through retraining against a new biometric.
EXAMPLE 4: A parent in a household creates an account on the consumer IoT device for their child and selects
and manages the PIN or password that the child uses. The parent is an administrator on the
consumer IoT device and can restrict the child from changing the PIN or password.
EXAMPLE 5: To make it simple for the user to change a password, the manufacturer designs the password
change process in a way that it requires a minimal number of steps. The manufacturer explains the
process in a user manual and in a video tutorial.
An authentication mechanism used for authenticating users, whether it be a fingerprint, password or other token, needs
to have its value changeable. This is easier when this mechanism is part of the normal usage flow of the consumer IoT
device.
Provision 5.1-5 The consumer IoT device shall have a mechanism available which makes successful brute-force attacks
on authentication mechanisms via network interfaces impracticable unless the device has a resource constraint
determined by the use case that prevents the implementation.
EXAMPLE 6: A consumer IoT device has a limitation on the number of authentication attempts within a certain
time interval. It also uses increasing time intervals between attempts.
EXAMPLE 7: The client application is able to lock an account or to delay additional authentication attempts after
a limited number of failed authentication attempts.
This provision addresses attacks that perform "credential stuffing" or exhaust an entire key-space. It is important that
these types of attacks are detected by the consumer IoT device and defended against, whilst guarding against a related
threat of "resource exhaustion" and denial of service attacks.
5.2 Implement a means to manage reports of vulnerabilities
Manufacturers that provide IoT products have a duty of care to consumers and third parties who can be harmed by their
failure to have a CVD programme in place. Addi
...
SLOVENSKI STANDARD
01-november-2024
CYBER - Kibernetska varnost za uporabniški internet stvari: osnovne zahteve
CYBER - Cyber Security for Consumer Internet of Things: Baseline Requirements
Ta slovenski standard je istoveten z: ETSI EN 303 645 V3.1.3 (2024-09)
ICS:
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD
CYBER;
Cyber Security for Consumer Internet of Things:
Baseline Requirements
2 ETSI EN 303 645 V3.1.3 (2024-09)
Reference
REN/CYBER-00127
Keywords
cybersecurity, IoT, privacy
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2024.
All rights reserved.
ETSI
3 ETSI EN 303 645 V3.1.3 (2024-09)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 11
3.3 Abbreviations . 11
4 Implementation of the standard . 12
5 Cyber security provisions for consumer IoT . 12
5.0 Reporting implementation . 12
5.1 No universal default passwords . 13
5.2 Implement a means to manage reports of vulnerabilities . 14
5.3 Keep software updated . 16
5.4 Securely store sensitive security parameters . 20
5.5 Communicate securely . 21
5.6 Minimize exposed attack surfaces . 22
5.7 Ensure software integrity . 24
5.8 Ensure that personal data is secure . 24
5.9 Make systems resilient to outages . 25
5.10 Examine system telemetry data . 25
5.11 Make it easy for users to delete user data . 25
5.12 Make installation and maintenance of devices easy . 26
5.13 Validate input data. 27
6 Data protection provisions for consumer IoT . 28
Annex A (informative): Basic concepts and models . 30
A.1 Architecture . 30
A.2 Device states . 32
A.3 Interfaces . 34
Annex B (informative): Implementation conformance statement pro forma . 36
Annex C (informative): Change history . 40
History . 41
ETSI
4 ETSI EN 303 645 V3.1.3 (2024-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association. ®
BLUETOOTH is a trademark registered and owned by Bluetooth SIG, Inc.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER).
National transposition dates
Date of adoption of this EN: 11 September 2024
Date of latest announcement of this EN (doa): 31 December 2024
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 June 2025
Date of withdrawal of any conflicting National Standard (dow): 30 June 2025
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
5 ETSI EN 303 645 V3.1.3 (2024-09)
Introduction
As more devices in the home connect to the Internet, the cyber security and data protection of the Internet of Things
(IoT) becomes a growing concern. People entrust their personal data to an increasing number of online devices and
services. Products and appliances that have traditionally been offline are now connected and need to be designed to
withstand cyber threats.
The present document brings together widely considered good practices in security for Internet-connected consumer
devices in a set of high-level outcome-focused provisions. The objective of the present document is to support all
parties involved in the development and manufacturing of consumer IoT with guidance on securing their products.
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security and data protection solutions appropriate for their products.
The present document is not intended to solve all security, data protection and privacy challenges associated with
consumer IoT. It also does not focus on protecting against attacks that are prolonged/sophisticated or that require
sustained physical access to the device. Rather, the focus is on the technical controls and organizational policies that
matter most in addressing the most significant and widespread security shortcomings. Overall, a baseline level of
security and data protection is considered; this is intended to protect against elementary attacks on fundamental design
weaknesses (such as the use of easily guessable passwords).
The present document provides a set of baseline provisions applicable to all consumer IoT devices. It is intended to be
complemented by other standards defining more specific provisions and fully testable and/or verifiable requirements for
specific devices which, together with the present document, will facilitate the development of assurance schemes.
A clause in the present document in some cases begins with general information about the context of the following
provisions. A provision is followed by explanatory text describing, where appropriate, the intent of the provision and
how the provision might be implemented. Further information on implementation examples is given in ETSI
TR 103 621 [i.31].
Many consumer IoT devices and their associated services process and store personal data, the present document can
help in ensuring that these are compliant with the General Data Protection Regulation (GDPR) [i.7]. Security by design
is an important principle that is endorsed by the present document.
ETSI TS 103 701 [i.19] provides guidance on how to assess and assure IoT products against provisions within the
present document.
The provisions in the present document have been developed following a review of published standards,
recommendations and guidance on IoT security and privacy, including: ETSI TR 103 305-3 [i.1], ETSI
TR 103 309 [i.2], ENISA Baseline Security Recommendations [i.8], UK Department for Digital, Culture, Media and
Sport (DCMS) Secure by Design Report [i.9], IoT Security Foundation Compliance Framework [i.10], GSMA IoT
Security Guidelines and Assessment [i.11], ETSI TR 103 533 [i.12], DIN SPEC 27072 [i.20] and OWASP Internet of
Things [i.23].
NOTE: Mappings of the landscape of IoT security standards, recommendations and guidance are available in
ENISA Baseline Security Recommendations for IoT - Interactive Tool [i.15] and in Copper Horse
Mapping Security & Privacy in the Internet of Things [i.14].
As consumer IoT products become increasingly secure, it is envisioned that future revisions of the present document
will mandate provisions that are currently recommendations in the present document.
ETSI
6 ETSI EN 303 645 V3.1.3 (2024-09)
1 Scope
The present document specifies high-level security and data protection provisions for consumer IoT devices that are
connected to network infrastructure (such as the Internet or home network) and their interactions with associated
services. A non-exhaustive list of examples of consumer IoT devices includes:
• connected children's toys and baby monitors;
• connected smoke detectors, door locks and window sensors;
• IoT gateways, base stations and hubs to which multiple devices connect;
• smart cameras, smart speakers and smart Televisions together with their remote controls;
• wearable health trackers;
• connected home automation and alarm systems, especially their gateways and hubs;
• connected appliances, such as washing machines and fridges; and
• smart home assistants.
Moreover, the present document addresses security considerations specific to constraints in device resources.
EXAMPLE: Typical device resources that might constrain the security capabilities are energy supply,
communication bandwidth, processing power or (non-)volatile memory capacity.
The present document provides basic guidance through examples and explanatory text for organizations involved in the
development and manufacturing of consumer IoT on how to implement those provisions. Table B.1 provides a schema
for the reader to give information about the implementation of the provisions.
Devices that are not consumer IoT devices, for example those that are primarily intended to be used in manufacturing,
healthcare or other industrial applications, are not in scope of the present document.
The present document has been developed primarily to help protect consumers, however, other users of consumer IoT
equally benefit from the implementation of the provisions set out here.
Annex A (informative) of the present document has been included to provide context to clauses 4, 5 and 6 (normative).
Annex A contains examples of device and reference architectures and an example model of device states including data
storage for each state.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
ETSI
7 ETSI EN 303 645 V3.1.3 (2024-09)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 305-3: "Cyber Security (CYBER); Critical Security Controls for Effective Cyber
Defence; Part 3: Internet of Things Sector".
[i.2] ETSI TR 103 309: "CYBER; Secure by Default - platform security technology".
[i.3] NIST Special Publication 800-63B: "Digital Identity Guidelines - Authentication and Lifecycle
Management".
[i.4] ISO/IEC 29147: "Information technology - Security techniques - Vulnerability Disclosure".
[i.5] OASIS csaf-v2.0: "Common Security Advisory Framework", version 2.0,edited by Langley Rock,
Stefan Hagen, and Thomas Schmidt, 18 November 2022 and the errata 01.
[i.6] ETSI TR 103 331: "Cyber Security (CYBER); Structured threat information sharing".
[i.7] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).
[i.8] ENISA: "Baseline Security Recommendations for IoT in the context of Critical Information
Infrastructures", November 2017, ISBN: 978-92-9204-236-3, doi: 10.2824/03228.
[i.9] UK Department for Digital, Culture, Media and Sport: "Secure by Design: Improving the cyber
security of consumer Internet of Things Report", March 2018.
[i.10] IoT Security Foundation: "IoT Security Assurance Framework", Release 3.0, November 2021.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice 2016/C 272/01: "The "Blue Guide" on the implementation of EU products
rules 2016" (Text with EEA relevance).
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
[i.16] IoT Security Foundation: "Understanding the Contemporary Use of Vulnerability Disclosure in
Consumer Internet of Things Product Companies".
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks". ®
[i.18] W3C : "Web of Things at W3C".
[i.19] ETSI TS 103 701: "CYBER; Cyber Security for Consumer Internet of Things: Conformance
Assessment of Baseline Requirements".
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA™: "Coordinated Vulnerability Disclosure (CVD) Programme".
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
ETSI
8 ETSI EN 303 645 V3.1.3 (2024-09)
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
[i.24] IEEE 802.15.4-2015™/Cor 1-2018: "IEEE Standard for Low-Rate Wireless Networks,
Corrigendum 1".
[i.25] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics".
[i.26] GSMA™: "SGP.22 Technical Specification v2.2.1".
[i.27] ISO/IEC 27005:2022: "Information technology - Security techniques - Information security risk
management". ®
[i.28] Microsoft Corporation: "The STRIDE Threat Model".
[i.29] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; 5G; Vocabulary for 3GPP Specifications
(3GPP TR 21.905)".
[i.30] ETSI TR 103 838: "Cyber Security; Guide to Coordinated Vulnerability Disclosure".
[i.31] ETSI TR 103 621: " Guide to Cyber Security for Consumer Internet of Things".
[i.32] FIRST: "Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure".
[i.33] ISO/IEC TR 5895: "Cybersecurity - Multi-party coordinated vulnerability disclosure and
handling".
[i.34] ISO/IEC 16500-6:1999: "Information technology Generic digital audio-visual systems".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
administrator: user who has the highest-privilege level possible for a user of the device, which can mean they are able
to change any configuration related to the intended functionality
associated services: digital services that, together with the device, are part of the overall consumer IoT product and that
are typically required to provide the product's intended functionality
EXAMPLE 1: Associated services can include mobile applications, cloud computing/storage and third party
Application Programming Interfaces (APIs).
EXAMPLE 2: A device transmits telemetry data to a third-party service chosen by the device manufacturer. This
service is an associated service.
authentication mechanism: method used to prove the authenticity of an entity
NOTE: An "entity" can be either a user or machine.
EXAMPLE: An authentication mechanism can be the requesting of a password, scanning a QR code, or use of a
biometric fingerprint scanner.
authentication value: individual value of an attribute used by an authentication mechanism
EXAMPLE: When the authentication mechanism is to request a password, the authentication value can be a
character string. When the authentication mechanism is a biometric fingerprint recognition, the
authentication value can be the index fingerprint of the left hand.
ETSI
9 ETSI EN 303 645 V3.1.3 (2024-09)
best practice: measures that have been shown to provide appropriate security for the corresponding use case
NOTE 1: Appropriate security for the corresponding use case also considers properties of the technology, operating
environment and risk.
NOTE 2: Multiple organizations, such as SDOs and public authorities, maintain guides and catalogues of measures
that can be used to identify best practice.
EXAMPLE: Applying a security configuration for a specific functionality that takes into account common
attacks and is endorsed by multiple organizations such as SDOs and public authorities.
best practice cryptography: cryptography that is suitable for the corresponding use case and has no indications of a
feasible attack with current readily available techniques
NOTE 1: This does not refer only to the cryptographic primitives used, but also implementation, key generation and
handling of keys.
NOTE 2: Multiple organizations, such as SDOs and public authorities, maintain guides and catalogues of
cryptographic methods that can be used.
EXAMPLE: The device manufacturer uses a communication protocol and cryptographic library provided with
the IoT platform and where that library and protocol have been assessed against feasible attacks,
such as replay.
consumer: natural person who is acting for purposes that are outside her/his trade, business, craft or profession
NOTE: Organizations, including businesses of any size, use consumer IoT. For example, Smart Televisions are
frequently deployed in meeting rooms, and home security kits can protect the premises of small
businesses.
consumer IoT device: network-connected (and network-connectable) device that has relationships to associated
services and are used by the consumer typically in the home or as electronic wearables
NOTE 1: Consumer IoT devices are commonly also used in business contexts. These devices remain classified as
consumer IoT devices.
NOTE 2: Consumer IoT devices are often available for the consumer to purchase in retail environments. Consumer
IoT devices can also be commissioned and/or installed professionally.
critical security parameter: security-related confidential information whose disclosure or modification can
compromise the security of the device
EXAMPLE: Secret cryptographic keys, authentication values such as passwords, PINs, private components of
certificates.
debug interface: physical interface used by the manufacturer to communicate with the device during development or to
perform triage of issues with the device and that is not used as part of the consumer-facing functionality
EXAMPLE: Test points, UART, SWD, JTAG.
defined support period: minimum length of time, expressed as a period or by an end-date, for which a manufacturer
will provide security updates
NOTE: This definition focuses on security aspects and not other aspects related to product support such as
warranty.
device manufacturer: entity that creates an assembled final consumer IoT product, which is likely to contain the
products and components of many other suppliers
factory default: state of the device after factory reset or after final production/assembly
NOTE: This includes the physical device and software (including firmware) that is present on it after assembly.
initialization: process that activates the network connectivity of the device for operation and optionally sets
authentication features for a user or for network access
initialized state: state of the device after initialization
ETSI
10 ETSI EN 303 645 V3.1.3 (2024-09)
IoT product: consumer IoT device and its associated services
isolable: able to be removed from the network it is connected to, where any functionality loss caused is related only to
that connectivity and not to its main function; alternatively, able to be placed in a self-contained environment with other
devices if and only if the integrity of devices within that environment can be ensured
EXAMPLE: A Smart Fridge has a touchscreen-based interface that is network-connected. This interface can be
removed without stopping the fridge from keeping the contents chilled.
logical interface: virtual interface used to communicate with the device at a logical layer
NOTE 1: Typically, the semantic, syntactic, and symbolic attributes of information flows for logical interfaces are
specified. The are alternative definitions for logical interfaces e.g. in ISO/IEC 16500-6:1999 [i.34] that
utilize this property.
NOTE 2: A logical interface may utilize a network interface to exchange information with remote endpoints.
manufacturer: relevant economic operator in the supply chain (including the device manufacturer)
NOTE: This definition acknowledges the variety of actors involved in the consumer IoT ecosystem and the
complex ways by which they can share responsibilities. Beyond the device manufacturer, such entities
can also be, for example and depending on a specific case at hand: importers, distributors, integrators,
component and platform providers, software providers, IT and telecommunications service providers,
managed service providers and providers of associated services.
network interface: physical interface that can be used to access the functionality of consumer IoT via a network
owner: user who owns or who purchased the device
personal data: any information relating to an identified or identifiable natural person
NOTE: This term is used to align with well-known terminology but has no legal meaning within the present
document.
physical interface: physical port or air interface (such as radio, audio or optical) used to communicate with the device
at the physical layer
EXAMPLE: Radios, ethernet ports, serial interfaces such as USB, and those used for debugging.
public security parameter: security-related public information whose modification can compromise the security of the
device
EXAMPLE 1: A public key to verify the authenticity/integrity of software updates.
EXAMPLE 2: Public components of certificates.
remotely accessible: intended to be accessible from outside the local network
security module: set of hardware, software, and/or firmware that implements security functions
EXAMPLE: A device contains a hardware root of trust, a cryptographic software library that operates within a
trusted execution environment, and software within the operating system that enforces security
such as user separation and the update mechanism. These all make up the security module.
security update: software update that addresses security vulnerabilities either discovered by or reported to the
manufacturer
NOTE: Software updates can be purely security updates if the severity of the vulnerability requires a higher
priority fix.
sensitive security parameters: critical security parameters and public security parameters
software service: software component of a device that is used to support functionality
EXAMPLE: A runtime for the programming language used within the device software or a daemon that
exposes an API used by the device software, e.g. a cryptographic module's API.
ETSI
11 ETSI EN 303 645 V3.1.3 (2024-09)
telemetry data: data from a device that provide information related to the usage of that device which could help the
manufacturer to identify security-related issues
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
NOTE 1: Telemetry data cover usage data, performance data, but also sensor data which facilitate the monitoring of
the device's physical and environmental conditions. Therefore, telemetry data do not only help to identify
security-related issues, but also help to improve the device's performance and user experience.
NOTE 2: Depending on the content of the telemetry data, telemetry data such as usage data may be considered as
personal data.
unique per device: unique for each individual device of a given product class or type
user: natural person or organization
user interface: user facing interface of the consumer IoT device
EXAMPLE: Buttons, screens, speaker, audio/video recorder as part of the consumer IoT device or user facing
logical interfaces such as frontends of services provided by the consumer IoT device.
vulnerability management process: course of action in which an organization addresses and remediates a disclosed
vulnerability
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
ARP Address Resolution Protocol
ASLR Address Space Layout Randomization
CVD Coordinated Vulnerability Disclosure
CSAF Common Security Advisory Framework
DDoS Distributed Denial of Service
DHCP Dynamic Host Configuration Protocol
DLNA Digital Living Network Alliance
DNS Domain Name System
DSC Dedicated Security Components
ENISA European Union Agency for Network and Information Security
EU European Union
GDPR General Data Protection Regulation
GSM Global System for Mobile communications
GSMA GSM Association
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
IP Internet Protocol
ISO International Organization for Standardization
JTAG Joint Test Action Group
LAN Local Area Network
LoRaWAN Long Range Wide Area Network
LTE Long Term Evolution
MAC Media Access Control
MMU Memory Management Unit
MPCVD Multi-Party Coordinated Vulnerability Disclosure
MPU Memory Protection Unit
ETSI
12 ETSI EN 303 645 V3.1.3 (2024-09)
NFC Near Field Communication
NIST National Institute of Standards and Technology
NTP Network Time Protocol
NX No eXecute
OTP One-Time Password
OWASP Open Web Application Security Project
QR Quick Response
RES RESet
SBOM Software Bill of Materials
SDO Standards Development Organization
SE Secure Elements
SQL Structured Query Language
SSID Service Set IDentifier
STRIDE Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of
privilege
SWD Serial Wire Debug
TEE Trusted Execution Environment
TS Technical Specification
UART Universal Asynchronous Receiver-Transmitter
UI User Interface
UICC Universal Integrated Circuit Card
UK United Kingdom
USB Universal Serial Bus
WAN Wide Area Network
WPS Wi-Fi Protected Setup
4 Implementation of the standard
The implementation of provisions in the present document is informed by risk assessment and threat modelling (such as
ISO/IEC 27005:2022 [i.27] and STRIDE Threat Model [i.28]) and data protection and privacy impact assessments; that
are performed by the device manufacturer and/or other relevant entities and are out of scope of the present document.
For certain use cases and following risk assessment, it can be appropriate to apply additional provisions as well as those
contained within the present document. In all cases, security, data protection and privacy by design and by default
should be used to inform the product development process, following risk assessment, but that is out of scope of the
present document.
The present document sets a security and data protection baseline; however, due to the broad landscape of consumer
IoT it is recognized that the applicability of provisions is dependent on each device. The present document provides a
degree of flexibility through the use of non-mandatory "should" provisions (recommendations).
The present document defines the security requirements for the device, it does not define a testing or certification
method to assess the requirements against. Some methods of fulfilling the requirements in the present document can
impact testing and certification making it very difficult, or even impossible, to demonstrate compliance in certain test
regimes.
Testing and certification involving third party assessment is likely to require documentation, including architectural
design documentation, security requirements capture and analysis, threat models and environmental assumptions, policy
documentation for lifecycle management (including supply chain management), assessment certificates for any
components that are used to implement functionality required in the present document. These documentation
requirements will be defined by the testing regime and are out of scope of the present document. A way to assess
conformance to the present document is specified in ETSI TS 103 701 [i.19].
5 Cyber security provisions for consumer IoT
5.0 Reporting implementation
Provision 5.0-1 A justification shall be recorded for each recommendation in the present document that is considered to
be not applicable for or not fulfilled by the consumer IoT device.
ETSI
13 ETSI EN 303 645 V3.1.3 (2024-09)
It is recommended that the manufacturer conducts a threat modelling to identify, analyse and mitigate threats to the
device.
Table B.1 provides a schema to record these justifications in a structured manner. This is to allow other stakeholders
(e.g. assurance assessors, members of the supply chain, security researchers or retailers) to determine whether
provisions have been applied correctly and appropriately.
EXAMPLE 1: The manufacturer publishes a completed version of table B.1 alongside the product description on
their website.
EXAMPLE 2: The manufacturer completes table B.1 for internal record keeping. Sometime later, an external
assurance organization assesses a product against the present document and requests information
relating to the product's security design. The manufacturer can easily provide this information as it
is contained within table B.1.
Cases where a provision is not applicable or not fulfilled by the consumer IoT device can include:
• when the use case of a device determines constraints in resources that prevent the implementation of certain
security measures or certain security measures are not appropriate to the identified risk (security or privacy);
• where the functionality described in the provision is not included (e.g. a device that only presents data without
requiring authentication);
• when the use case for the device requires compliance with additional industry or regulatory requirements that
preclude compliance with the provision.
EXAMPLE 3: The consumer IoT device and associated service processes payments and is therefore required to
comply with the payment card industry specifications and for transaction processing and industry
and regulatory requirements for fraud monitoring. Fraud monitoring can conflict with
provision 5.11-2 that recommends allowing users to be able to delete all personal data on the
associated service, potentially including the records necessary to detect fraudulent activity.
5.1 No universal default passwords
Provision 5.1-1 Where passwords are used to authenticate users against the device or for machine-to-machine
authentication, and in any state other than the factory default, all consumer IoT device passwords shall be unique per
device or defined by the user.
NOTE 1: There are many mechanisms used for performing authentication, and passwords are not the only
mechanism for authenticating a user to a device. However if they are used, following best practice on
passwords is encouraged according to NIST Special Publication 800-63B [i.3].
NOTE 2: Standard pairing codes are not considered as passwords used for machine-to-machine authentication.
Many consumer IoT devices are sold with universal default usernames and passwords (such as "admin, admin") for user
interfaces through to network protocols. Continued usage of universal default values has been the source of many
security issues in IoT [i.17] and the practice needs to be discontinued. The above provision can be achieved by the use
of pre-installed passwords that are unique per device and/or by requiring the user to choose a password that follows best
practice as part of initialization, or by some other method that does not use passwords.
EXAMPLE 1: During initialization a consumer IoT device generates certificates that are used to authenticate a
user to the consumer IoT device via an associated service like a mobile application.
To increase security, multi-factor authentication, such as use of a password plus OTP procedure, can be used to better
protect the consumer IoT device or an associated service. Consumer IoT device security can further be strengthened by
having unique and immutable identities.
Provision 5.1-2 Where pre-installed unique per device passwords are used to authenticate users against the device or
for machine-to-machine authentication, these shall be generated with a mechanism that reduces the risk of automated
attacks against a class or type of consumer IoT device.
EXAMPLE 2: Pre-installed passwords are sufficiently randomized.
ETSI
14 ETSI EN 303 645 V3.1.3 (2024-09)
As a counter-example, passwords with incremental counters (such as "password1", "password2" and so on) are easily
guessable. Further, using a password that is related in an obvious way to public information (sent over the air or within ®
SSID, can allow for password retrieval using automated means.
a network), such as MAC address or Wi-Fi
Provision 5.1-2A Passwords should not be used for machine-to-machine authentication.
Using human-memorable passwords for machine-to-machine authentication is generally not appropriate, but pre-shared
keys can be appropriate when their use follows best practice.
Provision 5.1-3 Authentication mechanisms used to authenticate users against the consumer IoT device or used for
machine-to-machine authentication shall use best practice cryptography, appropriate to the properties of the technology,
operating environment, risk and usage.
Provision 5.1-4 Where a user can authenticate against a consumer IoT device, the consumer IoT device shall provide to
the user or an administrator a simple mechanism to change the authentication value used.
EXAMPLE 3: For biometric authentication values the device manufacturer allows this change in authentication
value through retraining against a new biometric.
EXAMPLE 4: A parent in a household creates an account on the consumer IoT device for their child and selects
and manages the PIN or password that the child uses. The parent is an administrator on the
consumer IoT device and can restrict the child from changing the PIN or password.
EXAMPLE 5: To make it simple for the user to change a password, the manufacturer designs the password
change process in a way that it requires a minimal number of steps. The manufacturer explains the
process in a user manual and in a video tutorial.
An authentication mechanism used for authenticating users, whether it be a fingerprint, password or other token, needs
to have its value changeable. This is easier when this mechanism is part of the normal usage flow of the consumer IoT
device.
Provision 5.1-5 The consumer IoT device shall have a mechanism available which makes successful brute-force attacks
on authenticati
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...