ETSI EN 303 645 V2.1.1 (2020-06)
CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements
CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements
REN/CYBER-0048
CYBER - Kibernetska varnost za porabniški internet stvari: osnovne zahteve
General Information
Standards Content (Sample)
Draft ETSI EN 303 645 V2.0.0 (2019-11)
EUROPEAN STANDARD
CYBER;
Cyber Security for Consumer Internet of Things
2 Draft ETSI EN 303 645 V2.0.0 (2019-11)
Reference
REN/CYBER-0048
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 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://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
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 2019.
All rights reserved.
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.
ETSI
3 Draft ETSI EN 303 645 V2.0.0 (2019-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
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 Security and data protection provisions for consumer IoT. 11
4.0 Reporting implementation . 11
4.1 No universal default passwords . 12
4.2 Implement a means to manage reports of vulnerabilities . 13
4.3 Keep software updated . 14
4.4 Securely store sensitive security parameters . 16
4.5 Communicate securely . 16
4.6 Minimize exposed attack surfaces . 17
4.7 Ensure software integrity . 18
4.8 Ensure that personal data is protected . 18
4.9 Make systems resilient to outages . 19
4.10 Examine system telemetry data . 19
4.11 Make it easy for consumers to delete personal data . 20
4.12 Make installation and maintenance of devices easy . 20
4.13 Validate input data. 21
Annex A (informative): Basic concepts and models . 22
A.1 Architecture . 22
A.2 Device states . 24
Annex B (informative): Implementation pro forma . 27
History . 30
ETSI
4 Draft ETSI EN 303 645 V2.0.0 (2019-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
Foreword
This draft European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER) in co-
operation with CEN/CENELEC JTC 13 (Cybersecurity and Data Protection) and is now submitted for the combined
Public Enquiry and Vote phase of the ETSI standards 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.
Introduction
As more devices in the home connect to the Internet, the cyber security 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 practice 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.
ETSI
5 Draft ETSI EN 303 645 V2.0.0 (2019-11)
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security solutions appropriate for their products.
The present document is not intended to solve all security challenges associated with consumer IoT. 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 is considered; this is intended to protect against elementary
attacks on fundamental design weaknesses (such as the use of easily guessable passwords).
As much of consumer IoT and the 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.20] 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 review of published standards,
recommendations and guidance on IoT security and privacy [i.1], [i.2], [i.8], [i.9], [i.10], [i.11], [i.12], [i.20] and [i.23].
NOTE: Mappings of the landscape of IoT security standards, recommendations and guidance are available [i.14]
and [i.15].
ETSI
6 Draft ETSI EN 303 645 V2.0.0 (2019-11)
1 Scope
The present document specifies high-level provisions for the security of consumer IoT devices, that are connected to
network infrastructure (such as the Internet or home network) and their relationships to associated services. These
relationships encompass both network communications and handling of personal data. A non-exhaustive list of
examples of consumer IoT devices include:
• connected children's toys and baby monitors;
• connected safety-relevant products such as smoke detectors and door locks;
• IoT base stations and hubs to which multiple devices connect;
• smart cameras, TVs and speakers;
• 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 constrained devices, such as sensors and actuators. Such devices typically
have limited ability to process, communicate or store data, or limited user interfaces, which affects security
considerations.
EXAMPLE: Window contact sensors, flood sensors and energy switches are typically constrained devices.
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.
Applicability of these provisions depends on risk analysis; this is performed by the device manufacturer and/or other
relevant entities and is out of scope of the present document. For certain use cases and following risk assessment, it can
be appropriate to apply additional provisions than those contained within the present document. The present document
provides a foundation level of security for such higher assurance level use cases.
IoT products primarily intended to be used in manufacturing, healthcare or for 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 main clause 4 (normative).
Annex A contains examples of device and reference architectures, an example model of device states including data
storage for each state and additional description of key stakeholders.
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.
ETSI
7 Draft ETSI EN 303 645 V2.0.0 (2019-11)
The following referenced documents are necessary for the application of the present document.
Not applicable.
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; Critical Security Controls for Effective Cyber Defence; Part 3:
Service Sector Implementations".
[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".
NOTE: Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.
[i.4] ISO/IEC 29147: "Information technology --Security techniques -- Vulnerability Disclosure".
NOTE: Available at https://www.iso.org/standard/45170.html.
[i.5] CSAF: "Common Vulnerability Reporting Framework (CVRF)".
NOTE: Available at http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html.
[i.6] ETSI TR 103 331: "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.
NOTE: Available at https://www.gov.uk/government/collections/secure-by-design.
[i.10] IoT Security Foundation: "IoT Security Compliance Framework", Release 2 December 2018.
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-IoT-Security-
Compliance-Framework-Release-2.0-December-2018.pdf.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
NOTE: Available at https://www.gsma.com/iot/iot-security/iot-security-guidelines/.
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice: The "Blue Guide" on the implementation of EU products rules 2016 (Text
with EEA relevance), 2016/C 272/01.
NOTE: Available in the Official Journal of the European Union, https://eur-lex.europa.eu/legal-
content/EN/ALL/?uri=OJ:C:2016:272:TOC.
ETSI
8 Draft ETSI EN 303 645 V2.0.0 (2019-11)
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
NOTE: Available at https://iotsecuritymapping.uk/.
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
NOTE: Available at https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot/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".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerability-
Disclosure-Design-v4.pdf.
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks".
NOTE: Available at https://blog.f-secure.com/iot-threats/.
[i.18] W3C: "Web of Things at W3C".
NOTE: Available at https://www.w3.org/WoT/.
[i.19] ETSI TS 103 701: "CYBER; Cybersecurity assessment for consumer IoT products".
NOTE: It is under development.
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA: "Coordinated Vulnerability Disclosure (CVD) Programme".
NOTE: Available at https://www.gsma.com/security/gsma-coordinated-vulnerability-disclosure-programme/.
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability-
Disclosure_WG4_2017.pdf.
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
NOTE: Available at https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10.
[i.24] IEEE™ 802.15.4-2015: "IEEE Standard for Low-Rate Wireless Networks".
NOTE: Available at https://standards.ieee.org/content/ieee-standards/en/standard/802_15_4-2015.html.
[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".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
administrator: consumer who is at least intermittently a user and has the highest-privilege level in relation to the
device and is able to change any configuration related to the intended functionality
ETSI
9 Draft ETSI EN 303 645 V2.0.0 (2019-11)
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: Associated services can include mobile applications, cloud computing/storage and third party
Application Programming Interfaces (APIs).
authentication mechanism: method used to prove the authenticity of a consumer
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 cryptography: cryptography that is suitable for the corresponding use case and has no indications of a
feasible attack with current readily available techniques
NOTE: This does not refer only to the cryptographic primitives used, but also implementation, key generation and
handling of keys.
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.
constrained device: device which has physical limitations in either the ability to process data, the ability to
communicate data, the ability to store data or the ability to interact with the user
NOTE: Physical limitations can be due to power supply, battery life, processing power, physical access, limited
functionality, limited memory or limited network bandwidth. These limitations can require a constrained
device to be supported by another device, such as a base station or companion device.
EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device.
EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware
replacement or network isolation being the only options to manage a security vulnerability.
EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations.
Performing high power cryptographic operations would quickly reduce the battery life, so it relies
on a base station or hub to perform validations on updates.
EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing.
EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information.
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 devices: network-connected (and network-connectable) devices that have relationships to associated
services and are used by the consumer typically in the home or as electronic wearables
NOTE: 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 secret information whose disclosure or modification can compromise the
security of a security module
EXAMPLE: Secret cryptographic keys, authentication values such as passwords, PINs, certificates or other
trust anchors.
ETSI
10 Draft ETSI EN 303 645 V2.0.0 (2019-11)
defined support period: minimum length of time, expressed as a period or by an end-date, for which a device will
receive security updates
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 reset or following final production/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
isolable: able to be removed from the network it is connected to, without causing functionality loss, so that any
compromise affects only itself; 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
logical interface: software that utilizes a network interface to communicate over the network via channels or ports
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: consumer who owns or who purchased the device
personal data: any information relating to an identified or identifiable natural person
physical interface: physical port or radio used to communicate with the device at the physical layer
EXAMPLE: Radios, ethernet ports, serial interfaces such as USB, and those used for debugging purposes
including test points, UART, SWD or JTAG.
public security parameter: security related public information whose modification can compromise the security of a
security module
EXAMPLE: A public key to verify the authenticity/integrity of software updates
remotely accessible: intended to be accessible via wide area networks such as the Internet
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 V2.0.0 (2019-11)
telemetry: data from a device that can provide information to help the manufacturer identify issues or information
related to device usage
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
unique per device: unique for each individual device of a given product class or type
user: consumer who utilizes the device for its advertized function
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
ENISA European Union Agency for Network and Information Security
EU European Union
GDPR General Data Protection Regulation
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
NIST National Institute of Standards and Technology
OTP One-Time Password
QR Quick Response
SWD Serial Wire Debug
TEE Trusted Execution Environment
TS Technical Specification
UART Universal Asynchronous Receiver-Transmitter
UI User Interface
USB Universal Serial Bus
WAN Wide Area Network
4 Security and data protection provisions for consumer
IoT
4.0 Reporting implementation
The present document sets a security 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.
Provision 4.0-1 A justification shall be recorded for any provision that is considered to be not applicable for or not
supported by the consumer IoT product in question.
ETSI
12 Draft ETSI EN 303 645 V2.0.0 (2019-11)
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.
Cases where a provision is not applicable include, but are not limited to:
• when a device is constrained;
• where the functionality described in the provision is not included (e.g. a device that only presents data without
requiring authentication).
EXAMPLE: A window sensor with a limited battery life sends alerts via a remote associated service when
triggered, and has no incoming connection. It therefore will not have an authentication mechanism
while also being constrained.
4.1 No universal default passwords
Provision 4.1-1 Where passwords are used 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: 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 [i.3].
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 device generates certificates that are used to authenticate a user to the
device via an associated service like a mobile application.
To increase security, multi-factor authentication, such as use of a password plus OTP procedure, could be used for
authentication. Device security can further be strengthened by having unique and immutable identities.
Provision 4.1-2 Where pre-installed passwords are used, these shall be produced with a mechanism that reduces the risk
of automated attacks against a class or type of 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 4.1-3 Authentication mechanisms used to authenticate users against a device shall use best practice
cryptography, appropriate to the properties of the technology, risk and usage.
Provision 4.1-4 Where a user can authenticate against a device, the device should provide to the user an easily
accessible and intuitive mechanism to change the authentication value used.
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 device.
Provision 4.1-5 When the device is not a constrained device, it shall have a mechanism available which makes brute-
force attacks on authentication mechanisms via network interfaces impracticable.
EXAMPLE 3: A device has a limitation on the number of authentication attempts within a certain time interval. It
also uses increasing time intervals between attempts.
EXAMPLE 4: 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.
ETSI
13 Draft ETSI EN 303 645 V2.0.0 (2019-11)
4.2 Implement a means to manage reports of vulnerabilities
Provision 4.2-1 The manufacturer shall provide a public point of contact as part of a vulnerability disclosure policy so
that security researchers and others are able to report issues.
A vulnerability disclosure policy clearly specifies the process through which security researchers and others are able to
report issues and the roles of relevant stakeholders. Such policy can be made publicly available and updated as
necessary to further ensure transparency and clarity in the dealings of the company with security researchers, and vice
versa.
Coordinated Vulnerability Disclosure (CVD) is a set of processes for dealing with disclosures about potential security
vulnerabilities and to support the remediation of these vulnerabilities. CVD is standardized by the International
Organization for Standardization (ISO) in the ISO/IEC 29147 [i.4] on vulnerability disclosure and has been proven to
be successful in some large software companies around the world.
In the IoT industry, CVD is currently not well-established [i.16] as some companies are reticent about dealing with
security researchers. Here, CVD provides companies a framework to manage this process. This gives security
researchers an avenue to inform companies of security issues, puts companies ahead of the threat of malicious
exploitation and gives companies an opportunity to respond to and resolve vulnerabilities in advance of a public
disclosure.
Provision 4.2-2 Disclosed vulnerabilities should be acted on in a timely manner.
A "timely manner" for acting on vulnerabilities varies considerably and is incident-specific; however, conventionally,
the vulnerability process is completed within 90 days. A hardware fix can take considerably longer to address than a
software fix. Additionally, a fix that has to be deployed to devices can take time to roll out compared with a server
software fix.
Provision 4.2-3 Companies should continually monitor for, identify and rectify security vulnerabilities within products
and services they sell, produce, have produced and services they operate as part of the product security lifecycle.
Software solutions often contain open source and third party software components. Creating and maintaining list of all
software components and their sub-components is a pre-requisite to be able to monitor for product vulnerabilities.
Various tools exist to scan source code and binaries and build a so-called Software Bill of Materials (SBOM), which
identifies third party components and the versions used in the product. This information is then used to monitor for the
associated security and licensing risks of each identified software component.
Vulnerabilities are expected to be reported directly to the affected stakeholders in the first instance. If that is not
possible, vulnerabilities can be reported to national authorities. Companies are also encouraged to share information
with competent industry bodies such as the GSMA [i.21] and the IoT Security Foundation. Guidance on Coordinated
Vulnerability Disclosure is available from the IoT Security Foundation [i.22] which references ISO/IEC 29147 [i.4].
This is expected to be performed for devices within their defined support period. However, manufacturers can continue
this outside that period and release security updates to rectify vulnerabilities.
Companies that provide internet-connected devices, including consumer IoT, and associated services 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:
• Vulnerabilities related to single products or services: the problem is expected to be reported directly to the
affected stakeholder (usually the device manufacturer, IoT service provider or mobile application developer).
The source of these reports can be security researchers or industry peers.
• Systemic vulnerabilities: a stakeholder, such as a device manufacturer, can discover a problem that is
potentially systemic. Whilst fixing it in the device manufacturer's own product is crucial, there is significant
benefit to industry and consumers from sharing this information. Similarly, security researchers can also seek
to report such systemic vulnerabilities. For systemic vulnerabilities, a relevant competent industry body can
coordinate a wider scale response.
NOTE: The Common Vulnerability Reporting Framework (CVRF) [i.5] can also be useful to exchange
information on security vulnerabilities.
ETSI
14 Draft ETSI EN 303 645 V2.0.0 (2019-11)
Cyber security threat information sharing can support organizations in developing and producing secure products [i.6].
4.3 Keep software updated
Developing and deploying security updates in a timely manner is one of the most important actions a company can take
to protect its customers and the wider technical ecosystem.
Provision 4.3-1 All software components in consumer IoT devices should be securely updateable.
Provision 4.3-2 When the device is not a constrained device, it shall have an update mechanism for the secure
installation of updates.
"Securely updateable" and "secure installation" means that there are adequate measures to prevent an attacker misusing
the update mechanism.
EXAMPLE 1: Measures could include the use of authentic software update servers, integrity protected
communications channels, verifying the authenticity and integrity of software updates and an anti-
rollback policy based on version checking. It is recognized that there are great variances in
software update mechanisms and what constitutes "installation".
Update mechanisms can range from the device downloading the update directly from a remote server, transmitted from
a mobile application or transferred over a USB connection. If an attacker compromises this mechanism, it allows for a
malicious version of the software to be installed on the device.
Provision 4.3-3 The model designation of the consumer IoT device shall be clearly recognizable, either by labelling on
the device or via a physical interface.
This is often performed by communicating with a device over a logical interface, however it can also be part of a UI.
EXAMPLE 2: A device has a HTTP API that reports the model designation (after user authentication).
Knowledge of the specific designation of the device is often required to check the defined support period of software
updates or the availability of software updates.
Provision 4.3-4 The device shall use best practice cryptography to facilitate secure update mechanisms.
Provision 4.3-5 Security updates shall be timely.
"Timely" in the context of security updates can vary, depending on the particular issue and fix, as well as other factors
such as the ability to reach a device or constrained device considerations. It is important that a security update that fixes
a critical vulnerability (i.e. one with potentially adverse effects of a large scale) is handled with appropriate priority by
the manufacturer. The latter will need to be ready to provide sufficient evidence that the priority with which security
updates have been handled has been appropriate to the risk resulting from the respective security issues. Due to the
complex structure of modern software and the ubiquity of communication platforms, multiple stakeholders can be
involved in a security update.
EXAMPLE 3: A particular software update involves a third party vendor of software libraries, an IoT device
manufacturer, and an IoT service platform operator. Collaboration between these stakeholders
ensures appropriate timeliness of the software update.
Provision 4.3-6 The device should verify the authenticity and integrity of software updates.
A common approach for confirming that an update is valid is to verify its integrity and authenticity. This can be done on
the device; however, constrained devices can have power limitations that make performing cryptographic operations
costly. In such cases, verification could be performed by another device that is trusted to perform this verification. The
verified update would then be sent over a secure channel to the device. Performing verification of updates at a hub and
then on the device, can reduce the risk of compromise.
Provision 4.3-7 The manufacturer should inform the consumer in a recognisable and apparent manner that a security
update is required together with information on the need for that update.
NOTE 1: The appropriate entity is decided by the relevant jurisdiction.
Provision 4.3-8 The manufacturer shall publish, in an accessible way that is clear and transparent to the consumer, the
defined support period, including the reasons for the length of the period.
ETSI
15 Draft ETSI EN 303 645 V2.0.0 (2019-11)
When purchasing a product, the consumer expects this period of software update support to be made clear.
Provision 4.3-9 For constrained devices that cannot have their software updated, the rationale for the absence of
software updates, the period and method of hardware replacement support and a defined support period should be
published by the manufacturer in an accessible way that is clear and transparent to the consumer.
Provision 4.3-10 For constrained devices that cannot have their software updated, the product should be isolable and
the hardware replaceable.
There are some situations where devices cannot be patched. For constrained devices a replacement plan needs to be in
place and be clearly communicated to the consumer. This plan would typically detail a schedule for when technologies
wil
...
Final draft ETSI EN 303 645 V2.1.0 (2020-04)
EUROPEAN STANDARD
CYBER;
Cyber Security for Consumer Internet of Things:
Baseline Requirements
2 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
Reference
REN/CYBER-0048
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 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://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
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 2020.
All rights reserved.
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.
ETSI
3 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 11
3.3 Abbreviations . 12
4 Reporting implementation . 12
5 Cyber security provisions for consumer IoT . 13
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 . 18
5.5 Communicate securely . 19
5.6 Minimize exposed attack surfaces . 20
5.7 Ensure software integrity . 21
5.8 Ensure that personal data is secure . 21
5.9 Make systems resilient to outages . 22
5.10 Examine system telemetry data . 22
5.11 Make it easy for users to delete user data . 23
5.12 Make installation and maintenance of devices easy . 23
5.13 Validate input data. 24
6 Data protection provisions for consumer IoT . 24
Annex A (informative): Basic concepts and models . 25
A.1 Architecture . 25
A.2 Device states . 27
Annex B (informative): Implementation conformance statement pro forma . 29
History . 32
ETSI
4 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
Foreword
This final draft European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER),
and is now submitted for the Vote phase of the ETSI standards 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.
Introduction
As more devices in the home connect to the Internet, the cyber security 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 practice 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.
ETSI
5 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security solutions appropriate for their products.
The present document is not intended to solve all security 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 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.
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 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 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
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. The associated services are out of scope. 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, TVs and speakers;
• 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 constrained devices.
EXAMPLE: Window contact sensors, flood sensors and energy switches are typically constrained devices.
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 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
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; Critical Security Controls for Effective Cyber Defence; Part 3:
Service Sector Implementations".
[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".
NOTE: Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.
[i.4] ISO/IEC 29147: "Information technology - Security techniques - Vulnerability Disclosure".
NOTE: Available at https://www.iso.org/standard/45170.html.
[i.5] OASIS: "CSAF Common Vulnerability Reporting Framework (CVRF)".
NOTE: Available at http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html.
[i.6] ETSI TR 103 331: "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.
NOTE: Available at https://www.gov.uk/government/collections/secure-by-design.
[i.10] IoT Security Foundation: "IoT Security Compliance Framework", Release 2 December 2018.
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-IoT-Security-
Compliance-Framework-Release-2.0-December-2018.pdf.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
NOTE: Available at https://www.gsma.com/iot/iot-security/iot-security-guidelines/.
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice: The "Blue Guide" on the implementation of EU products rules 2016 (Text
with EEA relevance), 2016/C 272/01.
NOTE: Available in the Official Journal of the European Union, https://eur-lex.europa.eu/legal-
content/EN/ALL/?uri=OJ:C:2016:272:TOC.
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
NOTE: Available at https://iotsecuritymapping.uk/.
ETSI
8 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
NOTE: Available at https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot/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".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerability-
Disclosure-Design-v4.pdf.
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks".
NOTE: Available at https://blog.f-secure.com/iot-threats/.
[i.18] W3C: "Web of Things at W3C".
NOTE: Available at https://www.w3.org/WoT/.
[i.19] ETSI TS 103 701: "CYBER; Cybersecurity assessment for consumer IoT products".
NOTE: It is under development.
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA: "Coordinated Vulnerability Disclosure (CVD) Programme".
NOTE: Available at https://www.gsma.com/security/gsma-coordinated-vulnerability-disclosure-programme/.
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability-
Disclosure_WG4_2017.pdf.
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
NOTE: Available at https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10.
[i.24] IEEE 802.15.4™-2015: "IEEE Standard for Low-Rate Wireless Networks".
NOTE: Available at https://standards.ieee.org/content/ieee-standards/en/standard/802_15_4-2015.html.
[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:2018: "Information technology - Security techniques - Information security risk
management".
[i.28] Microsoft Corporation: "The STRIDE Threat Model".
NOTE: Available at https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx.
[i.29] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Vocabulary for 3GPP Specifications (3GPP
TR 21.905)".
ETSI
9 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
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 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.
constrained device: device which has physical limitations in either the ability to process data, the ability to
communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its
intended use
NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited
functionality, limited memory or limited network bandwidth. These limitations can require a constrained
device to be supported by another device, such as a base station or companion device.
EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device.
EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware
replacement or network isolation being the only options to manage a security vulnerability.
EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations.
Performing high power cryptographic operations would quickly reduce the battery life, so it relies
on a base station or hub to perform validations on updates.
EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing.
EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information.
ETSI
10 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic
primitives used by those protocols is not constrained.
EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security).
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 secret information whose disclosure or modification can compromise the
security of a security module
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
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: software implementation that utilizes a network interface to communicate over the network via
channels or ports
manufacturer: relevant economic operator in the supply chain (including the device manufacturer)
ETSI
11 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
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 a
security module
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.
telemetry: data from a device that can provide information to help the manufacturer identify issues or information
related to device usage
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
unique per device: unique for each individual device of a given product class or type
user: natural person or organization
3.2 Symbols
Void.
ETSI
12 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
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
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
NIST National Institute of Standards and Technology
OTP One-Time Password
QR Quick Response
SBOM Software Bill of Materials
SDO Standards Development Organization
SE Secure Elements
SWD Serial Wire Debug
TEE Trusted Execution Environment
TS Technical Specification
UART Universal Asynchronous Receiver-Transmitter
UI User Interface
USB Universal Serial Bus
WAN Wide Area Network
4 Reporting implementation
The implementation of provisions in the present document is informed by risk assessment and threat modelling (such as
ISO/IEC 27005:2018 [i.27] and STRIDE Threat Model [i.28]); this is performed by the device manufacturer and/or
other relevant entities and is 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.
The present document sets a security 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).
Provision 4-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.
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 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
Cases where a provision is not applicable or not fulfilled by the consumer IoT device can include:
• when a device is a constrained device in such a way that implementation of certain security measures is not
possible or 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).
EXAMPLE 3: A window sensor with a limited battery life sends alerts via a remote associated service when
triggered and is controlled via a hub. Due to its limited battery life and processing power compared
to other consumer IoT devices, it is a constrained device. In addition, because the user controls the
device via a hub, the user does not need to use passwords, or other authentication mechanisms, to
directly authenticate to the device.
5 Cyber security provisions for consumer IoT
5.1 No universal default passwords
Provision 5.1-1 Where passwords are used 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]. Using passwords for
machine to machine authentication is generally not appropriate.
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 device generates certificates that are used to authenticate a user to the
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 device or an associated service. 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, these shall be generated with a mechanism
that reduces the risk of automated attacks against a class or type of 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-3 Authentication mechanisms used to authenticate users against a device shall use best practice
cryptography, appropriate to the properties of the technology, risk and usage.
Provision 5.1-4 Where a user can authenticate against a device, the 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 device for their child and selects and manages
the PIN or password that the child uses. The parent is an administrator on the device and can
restrict the child from changing the PIN or password.
ETSI
14 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
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 device.
Provision 5.1-5 When the device is not a constrained device, it shall have a mechanism available which makes brute-
force attacks on authentication mechanisms via network interfaces impracticable.
EXAMPLE 6: A 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
Provision 5.2-1 The manufacturer shall make a vulnerability disclosure policy publicly available. This policy shall
include, at a minimum:
• contact information for the reporting of issues; and
• information on timelines for:
1) initial acknowledgement of receipt; and
2) status updates until the resolution of the reported issues.
A vulnerability disclosure policy clearly specifies the process through which security researchers and others are able to
report issues. Such policy can be updated as necessary to further ensure transparency and clarity in the dealings of the
manufacturer with security researchers, and vice versa.
Coordinated Vulnerability Disclosure (CVD) is a set of processes for dealing with disclosures about potential security
vulnerabilities and to support the remediation of these vulnerabilities. CVD is standardized by the International
Organization for Standardization (ISO) in the ISO/IEC 29147 [i.4] on vulnerability disclosure and has been proven to
be successful in some large software companies around the world.
In the IoT industry, CVD is currently not well-established [i.16] as some companies are reticent about dealing with
security researchers. Here, CVD provides companies a framework to manage this process. This gives security
researchers an avenue to inform companies of security issues, puts companies ahead of the threat of malicious
exploitation and gives companies an opportunity to respond to and resolve vulnerabilities in advance of a public
disclosure.
Provision 5.2-2 Disclosed vulnerabilities should be acted on in a timely manner.
A "timely manner" for acting on vulnerabilities varies considerably and is incident-specific; however, conventionally,
the vulnerability process is completed within 90 days for a software solution, including availability of patches and
notification of the issue. A hardware fix can take considerably longer to address than a software fix. Additionally, a fix
that has to be deployed to devices can take time to roll out compared with a server software fix.
Provision 5.2-3 Manufacturers should continually monitor for, identify and rectify security vulnerabilities within
products and services they sell, produce, have produced and services they operate during the defined support period.
NOTE 1: Manufacturers are expected to exercise due care for all software and hardware components used in the
product, this includes due care related to the selected third parties that provide associated services to
support the functions of the product.
ETSI
15 Final draft ETSI EN 303 645 V2.1.0 (2020-04)
Software solutions often contain open source and third party software components. Creating and maintaining list of all
software components and their sub-components is a pre-requisite to be able to monitor for product vulnerabilities.
Various tools exist to scan source code and binaries and build a so-called Software Bill of Materials (SBOM), which
identifies third party components and the versions used in the product. This information is then used to monitor for the
associated security and licensing risks of each identified software component.
Vulnerabilities are expected to be reported directly to the affected stakeholders in the first instance. If that is not
possible, vulnerabilities can be reported to national authorities. Manufacturers are also encouraged to share information
with competent industry bodies, such as the GSMA [i.21] and the IoT Security Foundation. Guidance on Coordinated
Vulnerability Disclosure is available from the IoT Security Foundation [i.22] which references ISO/IEC 29147 [i.4].
This is expected to be performed for devices within their defined support period. However, manufacturers can continue
this outside that period and release security updates to rectify 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:
• Vulnerabilities related to single products or services: the problem is expected to be reported directly to the
affected stakeholder (usually the device manufacturer, IoT service provider or mobile application developer).
The source of these reports can be security researchers or industry peers.
• Systemic vulnerab
...
EUROPEAN STANDARD
CYBER;
Cyber Security for Consumer Internet of Things:
Baseline Requirements
2 ETSI EN 303 645 V2.1.1 (2020-06)
Reference
REN/CYBER-0048
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 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://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
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 2020.
All rights reserved.
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.
ETSI
3 ETSI EN 303 645 V2.1.1 (2020-06)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 11
3.3 Abbreviations . 12
4 Reporting implementation . 12
5 Cyber security provisions for consumer IoT . 13
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 . 18
5.5 Communicate securely . 19
5.6 Minimize exposed attack surfaces . 20
5.7 Ensure software integrity . 21
5.8 Ensure that personal data is secure . 22
5.9 Make systems resilient to outages . 22
5.10 Examine system telemetry data . 23
5.11 Make it easy for users to delete user data . 23
5.12 Make installation and maintenance of devices easy . 24
5.13 Validate input data. 24
6 Data protection provisions for consumer IoT . 24
Annex A (informative): Basic concepts and models . 26
A.1 Architecture . 26
A.2 Device states . 28
Annex B (informative): Implementation conformance statement pro forma . 31
History . 34
ETSI
4 ETSI EN 303 645 V2.1.1 (2020-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER).
National transposition dates
Date of adoption of this EN: 19 June 2020
Date of latest announcement of this EN (doa): 30 September 2020
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 2021
Date of withdrawal of any conflicting National Standard (dow): 31 March 2021
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.
Introduction
As more devices in the home connect to the Internet, the cyber security 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 practice 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.
ETSI
5 ETSI EN 303 645 V2.1.1 (2020-06)
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security solutions appropriate for their products.
The present document is not intended to solve all security 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 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.
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 V2.1.1 (2020-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. The associated services are out of scope. 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, TVs and speakers;
• 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 constrained devices.
EXAMPLE: Window contact sensors, flood sensors and energy switches are typically constrained devices.
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 V2.1.1 (2020-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; Critical Security Controls for Effective Cyber Defence; Part 3:
Service Sector Implementations".
[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".
NOTE: Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.
[i.4] ISO/IEC 29147: "Information technology - Security techniques - Vulnerability Disclosure".
NOTE: Available at https://www.iso.org/standard/45170.html.
[i.5] OASIS: "CSAF Common Vulnerability Reporting Framework (CVRF)".
NOTE: Available at http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html.
[i.6] ETSI TR 103 331: "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.
NOTE: Available at https://op.europa.eu/en/publication-detail/-/publication/c37f8196-d96f-11e7-a506-
01aa75ed71a1/language-en/format-PDF/source-117211901.
[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.
NOTE: Available at https://www.gov.uk/government/collections/secure-by-design.
[i.10] IoT Security Foundation: "IoT Security Compliance Framework", Release 2 December 2018.
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-IoT-Security-
Compliance-Framework-Release-2.0-December-2018.pdf.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
NOTE: Available at https://www.gsma.com/iot/iot-security/iot-security-guidelines/.
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice: The "Blue Guide" on the implementation of EU products rules 2016 (Text
with EEA relevance), 2016/C 272/01.
NOTE: Available in the Official Journal of the European Union, https://eur-lex.europa.eu/legal-
content/EN/ALL/?uri=OJ:C:2016:272:TOC.
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
NOTE: Available at https://iotsecuritymapping.uk/.
ETSI
8 ETSI EN 303 645 V2.1.1 (2020-06)
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
NOTE: Available at https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot/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".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerability-
Disclosure-Design-v4.pdf.
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks".
NOTE: Available at https://blog.f-secure.com/iot-threats/.
[i.18] W3C: "Web of Things at W3C".
NOTE: Available at https://www.w3.org/WoT/.
[i.19] ETSI TS 103 701: "CYBER; Cybersecurity assessment for consumer IoT products".
NOTE: It is under development.
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA: "Coordinated Vulnerability Disclosure (CVD) Programme".
NOTE: Available at https://www.gsma.com/security/gsma-coordinated-vulnerability-disclosure-programme/.
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability-
Disclosure_WG4_2017.pdf.
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
NOTE: Available at https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10.
[i.24] IEEE 802.15.4™-2015: "IEEE Standard for Low-Rate Wireless Networks".
NOTE: Available at https://standards.ieee.org/content/ieee-standards/en/standard/802_15_4-2015.html.
[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:2018: "Information technology - Security techniques - Information security risk
management".
NOTE: Available at https://www.iso.org/standard/75281.html. ®
[i.28] Microsoft Corporation: "The STRIDE Threat Model".
NOTE: Available at https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx.
[i.29] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Vocabulary for 3GPP Specifications (3GPP
TR 21.905)".
ETSI
9 ETSI EN 303 645 V2.1.1 (2020-06)
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 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.
constrained device: device which has physical limitations in either the ability to process data, the ability to
communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its
intended use
NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited
functionality, limited memory or limited network bandwidth. These limitations can require a constrained
device to be supported by another device, such as a base station or companion device.
EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device.
EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware
replacement or network isolation being the only options to manage a security vulnerability.
EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations.
Performing high power cryptographic operations would quickly reduce the battery life, so it relies
on a base station or hub to perform validations on updates.
EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing.
EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information.
ETSI
10 ETSI EN 303 645 V2.1.1 (2020-06)
NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic
primitives used by those protocols is not constrained.
EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security).
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 secret information whose disclosure or modification can compromise the
security of a security module
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
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: software implementation that utilizes a network interface to communicate over the network via
channels or ports
ETSI
11 ETSI EN 303 645 V2.1.1 (2020-06)
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 a
security module
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.
telemetry: data from a device that can provide information to help the manufacturer identify issues or information
related to device usage
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
unique per device: unique for each individual device of a given product class or type
user: natural person or organization
3.2 Symbols
Void.
ETSI
12 ETSI EN 303 645 V2.1.1 (2020-06)
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
NIST National Institute of Standards and Technology
NX No execute
OTP One-Time Password
QR Quick Response
SBOM Software Bill of Materials
SDO Standards Development Organization
SE Secure Elements
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
UK United Kingdom
USB Universal Serial Bus
WAN Wide Area Network
4 Reporting implementation
The implementation of provisions in the present document is informed by risk assessment and threat modelling (such as
ISO/IEC 27005:2018 [i.27] and STRIDE Threat Model [i.28]); this is performed by the device manufacturer and/or
other relevant entities and is 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.
The present document sets a security 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).
Provision 4-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.
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.
ETSI
13 ETSI EN 303 645 V2.1.1 (2020-06)
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 a device is a constrained device in such a way that implementation of certain security measures is not
possible or 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).
EXAMPLE 3: A window sensor with a limited battery life sends alerts via a remote associated service when
triggered and is controlled via a hub. Due to its limited battery life and processing power compared
to other consumer IoT devices, it is a constrained device. In addition, because the user controls the
device via a hub, the user does not need to use passwords, or other authentication mechanisms, to
directly authenticate to the device.
5 Cyber security provisions for consumer IoT
5.1 No universal default passwords
Provision 5.1-1 Where passwords are used 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: 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]. Using passwords for
machine to machine authentication is generally not appropriate.
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 device generates certificates that are used to authenticate a user to the
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 device or an associated service. 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, these shall be generated with a mechanism
that reduces the risk of automated attacks against a class or type of 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-3 Authentication mechanisms used to authenticate users against a device shall use best practice
cryptography, appropriate to the properties of the technology, risk and usage.
ETSI
14 ETSI EN 303 645 V2.1.1 (2020-06)
Provision 5.1-4 Where a user can authenticate against a device, the 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 device for their child and selects and manages
the PIN or password that the child uses. The parent is an administrator on the 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 device.
Provision 5.1-5 When the device is not a constrained device, it shall have a mechanism available which makes brute-
force attacks on authentication mechanisms via network interfaces impracticable.
EXAMPLE 6: A 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
Provision 5.2-1 The manufacturer shall make a vulnerability disclosure policy publicly available. This policy shall
include, at a minimum:
• contact information for the reporting of issues; and
• information on timelines for:
1) initial acknowledgement of receipt; and
2) status updates until the resolution of the reported issues.
A vulnerability disclosure policy clearly specifies the process through which security researchers and others are able to
report issues. Such policy can be updated as necessary to further ensure transparency and clarity in the dealings of the
manufacturer with security researchers, and vice versa.
Coordinated Vulnerability Disclosure (CVD) is a set of processes for dealing with disclosures about potential security
vulnerabilities and to support the remediation of these vulnerabilities. CVD is standardized by the International
Organization for Standardization (ISO) in the ISO/IEC 29147 [i.4] on vulnerability disclosure and has been proven to
be successful in some large software companies around the world.
In the IoT industry, CVD is currently not well-established [i.16] as some companies are reticent about dealing with
security researchers. Here, CVD provides companies a framework to manage this process. This gives security
researchers an avenue to inform companies of security issues, puts companies ahead of the threat of malicious
exploitation and gives companies an opportunity to respond to and resolve vulnerabilities in advance of a public
disclosure.
Provision 5.2-2 Disclosed vulnerabilities should be acted on in a timely manner.
A "timely manner" for acting on vulnerabilities varies considerably and is incident-specific; however, conventionally,
the vulnerability process is completed within 90 days for a software solution, including availability of patches and
notification of the issue. A hardware fix can take considerably longer to address than a software fix. Additionally, a fix
that has to be deployed to devices can take time to roll out compared with a server software fix.
ETSI
15 ETSI EN 303 645 V2.1.1 (2020-06)
Provision 5.2-3 Manufacturers should continually monitor for, identify and rectify security vulnerabilities within
products and services they sell, produce, have produced and services they operate during the defined support period.
NOTE 1: Manufacturers are expected to exercise due care for all software and hardware components used in the
product, this includes due care related to the selected third parties that provide associated services to
support the functions of the product.
Software solutions often contain open source and third party software components. Creating and maintaining list of all
software components and their sub-components is a pre-requisite to be able to monitor for product vulnerabilities.
Various tools exist to scan source code and binaries and build a so-called Software Bill of Materials (SBOM), which
identifies third party components and the versions used in the product. This information is then used to monitor for the
associated security and licensing risks of each identified software component.
Vulnerabilities are expected to be reported directly to the affected stakeholders in the first instance. If that is not
possible, vulnerabilities can be reported to national authorities. Manufacturers are also encouraged to share information
with competent industry bodies, such as the GSMA [i.21] and the IoT Security Foundation. Guidance on Coordinated
Vulnerability Disclosure is available from the IoT Security Foundation [i.22] which references ISO/IEC 29147 [i.4].
This is expected to be performed for devices within their defined support period. However, manufacturers can continue
this outside that period and release security updates to rectify 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:
• Vulnerabilities related to single products or services: the problem is expected to be reported directly to the
affected stakeholder (usually the device manufacturer, I
...
SLOVENSKI STANDARD
01-september-2020
CYBER - Kibernetska varnost za porabniš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 V2.1.1 (2020-06)
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 V2.1.1 (2020-06)
Reference
REN/CYBER-0048
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 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://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
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 2020.
All rights reserved.
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.
ETSI
3 ETSI EN 303 645 V2.1.1 (2020-06)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 11
3.3 Abbreviations . 12
4 Reporting implementation . 12
5 Cyber security provisions for consumer IoT . 13
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 . 18
5.5 Communicate securely . 19
5.6 Minimize exposed attack surfaces . 20
5.7 Ensure software integrity . 21
5.8 Ensure that personal data is secure . 22
5.9 Make systems resilient to outages . 22
5.10 Examine system telemetry data . 23
5.11 Make it easy for users to delete user data . 23
5.12 Make installation and maintenance of devices easy . 24
5.13 Validate input data. 24
6 Data protection provisions for consumer IoT . 24
Annex A (informative): Basic concepts and models . 26
A.1 Architecture . 26
A.2 Device states . 28
Annex B (informative): Implementation conformance statement pro forma . 31
History . 34
ETSI
4 ETSI EN 303 645 V2.1.1 (2020-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER).
National transposition dates
Date of adoption of this EN: 19 June 2020
Date of latest announcement of this EN (doa): 30 September 2020
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 2021
Date of withdrawal of any conflicting National Standard (dow): 31 March 2021
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.
Introduction
As more devices in the home connect to the Internet, the cyber security 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 practice 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.
ETSI
5 ETSI EN 303 645 V2.1.1 (2020-06)
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security solutions appropriate for their products.
The present document is not intended to solve all security 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 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.
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 V2.1.1 (2020-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. The associated services are out of scope. 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, TVs and speakers;
• 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 constrained devices.
EXAMPLE: Window contact sensors, flood sensors and energy switches are typically constrained devices.
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 V2.1.1 (2020-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; Critical Security Controls for Effective Cyber Defence; Part 3:
Service Sector Implementations".
[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".
NOTE: Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.
[i.4] ISO/IEC 29147: "Information technology - Security techniques - Vulnerability Disclosure".
NOTE: Available at https://www.iso.org/standard/45170.html.
[i.5] OASIS: "CSAF Common Vulnerability Reporting Framework (CVRF)".
NOTE: Available at http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html.
[i.6] ETSI TR 103 331: "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.
NOTE: Available at https://op.europa.eu/en/publication-detail/-/publication/c37f8196-d96f-11e7-a506-
01aa75ed71a1/language-en/format-PDF/source-117211901.
[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.
NOTE: Available at https://www.gov.uk/government/collections/secure-by-design.
[i.10] IoT Security Foundation: "IoT Security Compliance Framework", Release 2 December 2018.
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-IoT-Security-
Compliance-Framework-Release-2.0-December-2018.pdf.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
NOTE: Available at https://www.gsma.com/iot/iot-security/iot-security-guidelines/.
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice: The "Blue Guide" on the implementation of EU products rules 2016 (Text
with EEA relevance), 2016/C 272/01.
NOTE: Available in the Official Journal of the European Union, https://eur-lex.europa.eu/legal-
content/EN/ALL/?uri=OJ:C:2016:272:TOC.
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
NOTE: Available at https://iotsecuritymapping.uk/.
ETSI
8 ETSI EN 303 645 V2.1.1 (2020-06)
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
NOTE: Available at https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot/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".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerability-
Disclosure-Design-v4.pdf.
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks".
NOTE: Available at https://blog.f-secure.com/iot-threats/.
[i.18] W3C: "Web of Things at W3C".
NOTE: Available at https://www.w3.org/WoT/.
[i.19] ETSI TS 103 701: "CYBER; Cybersecurity assessment for consumer IoT products".
NOTE: It is under development.
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA: "Coordinated Vulnerability Disclosure (CVD) Programme".
NOTE: Available at https://www.gsma.com/security/gsma-coordinated-vulnerability-disclosure-programme/.
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability-
Disclosure_WG4_2017.pdf.
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
NOTE: Available at https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10.
[i.24] IEEE 802.15.4™-2015: "IEEE Standard for Low-Rate Wireless Networks".
NOTE: Available at https://standards.ieee.org/content/ieee-standards/en/standard/802_15_4-2015.html.
[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:2018: "Information technology - Security techniques - Information security risk
management".
NOTE: Available at https://www.iso.org/standard/75281.html. ®
[i.28] Microsoft Corporation: "The STRIDE Threat Model".
NOTE: Available at https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx.
[i.29] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Vocabulary for 3GPP Specifications (3GPP
TR 21.905)".
ETSI
9 ETSI EN 303 645 V2.1.1 (2020-06)
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 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.
constrained device: device which has physical limitations in either the ability to process data, the ability to
communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its
intended use
NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited
functionality, limited memory or limited network bandwidth. These limitations can require a constrained
device to be supported by another device, such as a base station or companion device.
EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device.
EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware
replacement or network isolation being the only options to manage a security vulnerability.
EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations.
Performing high power cryptographic operations would quickly reduce the battery life, so it relies
on a base station or hub to perform validations on updates.
EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing.
EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information.
ETSI
10 ETSI EN 303 645 V2.1.1 (2020-06)
NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic
primitives used by those protocols is not constrained.
EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security).
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 secret information whose disclosure or modification can compromise the
security of a security module
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
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: software implementation that utilizes a network interface to communicate over the network via
channels or ports
ETSI
11 ETSI EN 303 645 V2.1.1 (2020-06)
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 a
security module
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.
telemetry: data from a device that can provide information to help the manufacturer identify issues or information
related to device usage
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
unique per device: unique for each individual device of a given product class or type
user: natural person or organization
3.2 Symbols
Void.
ETSI
12 ETSI EN 303 645 V2.1.1 (2020-06)
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
NIST National Institute of Standards and Technology
NX No execute
OTP One-Time Password
QR Quick Response
SBOM Software Bill of Materials
SDO Standards Development Organization
SE Secure Elements
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
UK United Kingdom
USB Universal Serial Bus
WAN Wide Area Network
4 Reporting implementation
The implementation of provisions in the present document is informed by risk assessment and threat modelling (such as
ISO/IEC 27005:2018 [i.27] and STRIDE Threat Model [i.28]); this is performed by the device manufacturer and/or
other relevant entities and is 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.
The present document sets a security 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).
Provision 4-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.
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.
ETSI
13 ETSI EN 303 645 V2.1.1 (2020-06)
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 a device is a constrained device in such a way that implementation of certain security measures is not
possible or 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).
EXAMPLE 3: A window sensor with a limited battery life sends alerts via a remote associated service when
triggered and is controlled via a hub. Due to its limited battery life and processing power compared
to other consumer IoT devices, it is a constrained device. In addition, because the user controls the
device via a hub, the user does not need to use passwords, or other authentication mechanisms, to
directly authenticate to the device.
5 Cyber security provisions for consumer IoT
5.1 No universal default passwords
Provision 5.1-1 Where passwords are used 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: 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]. Using passwords for
machine to machine authentication is generally not appropriate.
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 device generates certificates that are used to authenticate a user to the
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 device or an associated service. 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, these shall be generated with a mechanism
that reduces the risk of automated attacks against a class or type of 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-3 Authentication mechanisms used to authenticate users against a device shall use best practice
cryptography, appropriate to the properties of the technology, risk and usage.
ETSI
14 ETSI EN 303 645 V2.1.1 (2020-06)
Provision 5.1-4 Where a user can authenticate against a device, the 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 device for their child and selects and manages
the PIN or password that the child uses. The parent is an administrator on the 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 device.
Provision 5.1-5 When the device is not a constrained device, it shall have a mechanism available which makes brute-
force attacks on authentication mechanisms via network interfaces impracticable.
EXAMPLE 6: A 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
Provision 5.2-1 The manufacturer shall make a vulnerability disclosure policy publicly available. This policy shall
include, at a minimum:
• contact information for the reporting of issues; and
• information on timelines for:
1) initial acknowledgement of receipt; and
2) status updates until the resolution of the reported issues.
A vulnerability disclosure policy clearly specifies the process through which security researchers and others are able to
report issues. Such policy can be updated as necessary to further ensure transparency and clarity in the dealings of the
manufacturer with security researchers, and vice versa.
Coordinated Vulnerability Disclosure (CVD) is a set of processes for dealing with disclosures about potential security
vulnerabilities and to support the remediation of these vulnerabilities. CVD is standardized by the International
Organization for Standardization (ISO) in the ISO/IEC 29147 [i.4] on vulnerability disclosure and has been proven to
be successful in some large software companies around the world.
In the IoT industry, CVD is currently not well-established [i.16] as some companies are reticent about dealing with
security researchers. Here, CVD provides companies a framework to manage this process. This gives security
researchers an avenue to inform companies of security issues, puts companies ahead of the threat of malicious
exploitation and gives companies an opportunity to respond to and resolve vulnerabilities in advance of a public
disclosure.
Provision 5.2-2 Disclosed vulnerabilities should be acted on in a timely manner.
A "timely manner" for acting on vulnerabilities varies considerably and is incident-specific; however, conventionally,
the vulnerability process is completed within 90 days for a software solution, including availability of patches and
notification of the issue. A hardware fix can take considerably longer to address than a software fix. Additionally, a fix
that has to be deployed to devices can take time to roll out compared with a server software fix.
ETSI
15 ETSI EN 303 645 V2.1.1 (2020-06)
Provision 5.2-3 Manufacturers should continually monitor for, identify and rectify security vulnerabilities within
products and services they sell, produce, have produced and services they operate during the defined support period.
NOTE 1: Manufacturers are expected to exercise due care for all software and hardware components used in the
product, this includes due care related to the selected third parties that provide associated services to
support the functions of the product.
Software solutions often contain open source and third party software components. Creating and maintaining list of all
software components and their sub-components is a pre-requisite to be able to monitor for product vulnerabilities.
Various tools exist to scan source code and binaries and build a so-called Software Bill of Materials (SBOM), which
identifies third party components and the versions used in the product. This information is then used to monitor for the
associated security and licensing risks of each identified software component.
Vulnerabilities are expected to be reported directly to the affected stakeholders in the first instance. If that is not
possible, vulnerabiliti
...
SLOVENSKI STANDARD
01-september-2020
CYBER - Kibernetska varnost za uporabnike interneta stvari: osnovne zahteve
CYBER - Cyber Security for Consumer Internet of Things: Baseline Requirements
Ta slovenski standard je istoveten z: ETSI EN 303 645 V2.1.1 (2020-06)
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 V2.1.1 (2020-06)
Reference
REN/CYBER-0048
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 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://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
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 2020.
All rights reserved.
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.
ETSI
3 ETSI EN 303 645 V2.1.1 (2020-06)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 11
3.3 Abbreviations . 12
4 Reporting implementation . 12
5 Cyber security provisions for consumer IoT . 13
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 . 18
5.5 Communicate securely . 19
5.6 Minimize exposed attack surfaces . 20
5.7 Ensure software integrity . 21
5.8 Ensure that personal data is secure . 22
5.9 Make systems resilient to outages . 22
5.10 Examine system telemetry data . 23
5.11 Make it easy for users to delete user data . 23
5.12 Make installation and maintenance of devices easy . 24
5.13 Validate input data. 24
6 Data protection provisions for consumer IoT . 24
Annex A (informative): Basic concepts and models . 26
A.1 Architecture . 26
A.2 Device states . 28
Annex B (informative): Implementation conformance statement pro forma . 31
History . 34
ETSI
4 ETSI EN 303 645 V2.1.1 (2020-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Cyber Security (CYBER).
National transposition dates
Date of adoption of this EN: 19 June 2020
Date of latest announcement of this EN (doa): 30 September 2020
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 2021
Date of withdrawal of any conflicting National Standard (dow): 31 March 2021
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.
Introduction
As more devices in the home connect to the Internet, the cyber security 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 practice 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.
ETSI
5 ETSI EN 303 645 V2.1.1 (2020-06)
The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate
and implement security solutions appropriate for their products.
The present document is not intended to solve all security 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 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.
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 V2.1.1 (2020-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. The associated services are out of scope. 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, TVs and speakers;
• 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 constrained devices.
EXAMPLE: Window contact sensors, flood sensors and energy switches are typically constrained devices.
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 V2.1.1 (2020-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; Critical Security Controls for Effective Cyber Defence; Part 3:
Service Sector Implementations".
[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".
NOTE: Available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.
[i.4] ISO/IEC 29147: "Information technology - Security techniques - Vulnerability Disclosure".
NOTE: Available at https://www.iso.org/standard/45170.html.
[i.5] OASIS: "CSAF Common Vulnerability Reporting Framework (CVRF)".
NOTE: Available at http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html.
[i.6] ETSI TR 103 331: "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.
NOTE: Available at https://op.europa.eu/en/publication-detail/-/publication/c37f8196-d96f-11e7-a506-
01aa75ed71a1/language-en/format-PDF/source-117211901.
[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.
NOTE: Available at https://www.gov.uk/government/collections/secure-by-design.
[i.10] IoT Security Foundation: "IoT Security Compliance Framework", Release 2 December 2018.
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-IoT-Security-
Compliance-Framework-Release-2.0-December-2018.pdf.
[i.11] GSMA: "GSMA IoT Security Guidelines and Assessment".
NOTE: Available at https://www.gsma.com/iot/iot-security/iot-security-guidelines/.
[i.12] ETSI TR 103 533: "SmartM2M; Security; Standards Landscape and best practices".
[i.13] Commission Notice: The "Blue Guide" on the implementation of EU products rules 2016 (Text
with EEA relevance), 2016/C 272/01.
NOTE: Available in the Official Journal of the European Union, https://eur-lex.europa.eu/legal-
content/EN/ALL/?uri=OJ:C:2016:272:TOC.
[i.14] Copper Horse: "Mapping Security & Privacy in the Internet of Things".
NOTE: Available at https://iotsecuritymapping.uk/.
ETSI
8 ETSI EN 303 645 V2.1.1 (2020-06)
[i.15] ENISA: "Baseline Security Recommendations for IoT - Interactive Tool".
NOTE: Available at https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot/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".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerability-
Disclosure-Design-v4.pdf.
[i.17] F-Secure: "IoT threats: Explosion of 'smart' devices filling up homes leads to increasing risks".
NOTE: Available at https://blog.f-secure.com/iot-threats/.
[i.18] W3C: "Web of Things at W3C".
NOTE: Available at https://www.w3.org/WoT/.
[i.19] ETSI TS 103 701: "CYBER; Cybersecurity assessment for consumer IoT products".
NOTE: It is under development.
[i.20] DIN SPEC 27072: "Information Technology - IoT capable devices - Minimum requirements for
Information security".
[i.21] GSMA: "Coordinated Vulnerability Disclosure (CVD) Programme".
NOTE: Available at https://www.gsma.com/security/gsma-coordinated-vulnerability-disclosure-programme/.
[i.22] IoT Security Foundation: "Vulnerability Disclosure - Best Practice Guidelines".
NOTE: Available at https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability-
Disclosure_WG4_2017.pdf.
[i.23] OWASP Internet of Things (IoT) Top 10 2018.
NOTE: Available at https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10.
[i.24] IEEE 802.15.4™-2015: "IEEE Standard for Low-Rate Wireless Networks".
NOTE: Available at https://standards.ieee.org/content/ieee-standards/en/standard/802_15_4-2015.html.
[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:2018: "Information technology - Security techniques - Information security risk
management".
NOTE: Available at https://www.iso.org/standard/75281.html. ®
[i.28] Microsoft Corporation: "The STRIDE Threat Model".
NOTE: Available at https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx.
[i.29] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Vocabulary for 3GPP Specifications (3GPP
TR 21.905)".
ETSI
9 ETSI EN 303 645 V2.1.1 (2020-06)
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 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.
constrained device: device which has physical limitations in either the ability to process data, the ability to
communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its
intended use
NOTE 1: Physical limitations can be due to power supply, battery life, processing power, physical access, limited
functionality, limited memory or limited network bandwidth. These limitations can require a constrained
device to be supported by another device, such as a base station or companion device.
EXAMPLE 1: A window sensor's battery cannot be charged or changed by the user; this is a constrained device.
EXAMPLE 2: The device cannot have its software updated due to storage limitations, resulting in hardware
replacement or network isolation being the only options to manage a security vulnerability.
EXAMPLE 3: A low-powered device uses a battery to enable it to be deployed in a range of locations.
Performing high power cryptographic operations would quickly reduce the battery life, so it relies
on a base station or hub to perform validations on updates.
EXAMPLE 4: The device has no display screen to validate binding codes for Bluetooth pairing.
EXAMPLE 5: The device has no ability to input, such as via a keyboard, authentication information.
ETSI
10 ETSI EN 303 645 V2.1.1 (2020-06)
NOTE 2: A device that has a wired power supply and can support IP-based protocols and the cryptographic
primitives used by those protocols is not constrained.
EXAMPLE 6: A device is mains powered and communicates primarily using TLS (Transport Layer Security).
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 secret information whose disclosure or modification can compromise the
security of a security module
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
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: software implementation that utilizes a network interface to communicate over the network via
channels or ports
ETSI
11 ETSI EN 303 645 V2.1.1 (2020-06)
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 a
security module
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.
telemetry: data from a device that can provide information to help the manufacturer identify issues or information
related to device usage
EXAMPLE: A consumer IoT device reports software malfunctions to the manufacturer enabling them to
identify and remedy the cause.
unique per device: unique for each individual device of a given product class or type
user: natural person or organization
3.2 Symbols
Void.
ETSI
12 ETSI EN 303 645 V2.1.1 (2020-06)
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
NIST National Institute of Standards and Technology
NX No execute
OTP One-Time Password
QR Quick Response
SBOM Software Bill of Materials
SDO Standards Development Organization
SE Secure Elements
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
UK United Kingdom
USB Universal Serial Bus
WAN Wide Area Network
4 Reporting implementation
The implementation of provisions in the present document is informed by risk assessment and threat modelling (such as
ISO/IEC 27005:2018 [i.27] and STRIDE Threat Model [i.28]); this is performed by the device manufacturer and/or
other relevant entities and is 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.
The present document sets a security 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).
Provision 4-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.
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.
ETSI
13 ETSI EN 303 645 V2.1.1 (2020-06)
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 a device is a constrained device in such a way that implementation of certain security measures is not
possible or 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).
EXAMPLE 3: A window sensor with a limited battery life sends alerts via a remote associated service when
triggered and is controlled via a hub. Due to its limited battery life and processing power compared
to other consumer IoT devices, it is a constrained device. In addition, because the user controls the
device via a hub, the user does not need to use passwords, or other authentication mechanisms, to
directly authenticate to the device.
5 Cyber security provisions for consumer IoT
5.1 No universal default passwords
Provision 5.1-1 Where passwords are used 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: 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]. Using passwords for
machine to machine authentication is generally not appropriate.
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 device generates certificates that are used to authenticate a user to the
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 device or an associated service. 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, these shall be generated with a mechanism
that reduces the risk of automated attacks against a class or type of 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-3 Authentication mechanisms used to authenticate users against a device shall use best practice
cryptography, appropriate to the properties of the technology, risk and usage.
ETSI
14 ETSI EN 303 645 V2.1.1 (2020-06)
Provision 5.1-4 Where a user can authenticate against a device, the 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 device for their child and selects and manages
the PIN or password that the child uses. The parent is an administrator on the 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 device.
Provision 5.1-5 When the device is not a constrained device, it shall have a mechanism available which makes brute-
force attacks on authentication mechanisms via network interfaces impracticable.
EXAMPLE 6: A 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
Provision 5.2-1 The manufacturer shall make a vulnerability disclosure policy publicly available. This policy shall
include, at a minimum:
• contact information for the reporting of issues; and
• information on timelines for:
1) initial acknowledgement of receipt; and
2) status updates until the resolution of the reported issues.
A vulnerability disclosure policy clearly specifies the process through which security researchers and others are able to
report issues. Such policy can be updated as necessary to further ensure transparency and clarity in the dealings of the
manufacturer with security researchers, and vice versa.
Coordinated Vulnerability Disclosure (CVD) is a set of processes for dealing with disclosures about potential security
vulnerabilities and to support the remediation of these vulnerabilities. CVD is standardized by the International
Organization for Standardization (ISO) in the ISO/IEC 29147 [i.4] on vulnerability disclosure and has been proven to
be successful in some large software companies around the world.
In the IoT industry, CVD is currently not well-established [i.16] as some companies are reticent about dealing with
security researchers. Here, CVD provides companies a framework to manage this process. This gives security
researchers an avenue to inform companies of security issues, puts companies ahead of the threat of malicious
exploitation and gives companies an opportunity to respond to and resolve vulnerabilities in advance of a public
disclosure.
Provision 5.2-2 Disclosed vulnerabilities should be acted on in a timely manner.
A "timely manner" for acting on vulnerabilities varies considerably and is incident-specific; however, conventionally,
the vulnerability process is completed within 90 days for a software solution, including availability of patches and
notification of the issue. A hardware fix can take considerably longer to address than a software fix. Additionally, a fix
that has to be deployed to devices can take time to roll out compared with a server software fix.
ETSI
15 ETSI EN 303 645 V2.1.1 (2020-06)
Provision 5.2-3 Manufacturers should continually monitor for, identify and rectify security vulnerabilities within
products and services they sell, produce, have produced and services they operate during the defined support period.
NOTE 1: Manufacturers are expected to exercise due care for all software and hardware components used in the
product, this includes due care related to the selected third parties that provide associated services to
support the functions of the product.
Software solutions often contain open source and third party software components. Creating and maintaining list of all
software components and their sub-components is a pre-requisite to be able to monitor for product vulnerabilities.
Various tools exist to scan source code and binaries and build a so-called Software Bill of Materials (SBOM), which
identifies third party components and the versions used in the product. This information is then used to monitor for the
associated security and licensing risks of each identified software component.
Vulnerabilities are expected to be reported directly to the affected stakeholders in the first instance. If that is not
possible, vulnerabilit
...
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...