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.

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.

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.

Authentication mechanisms used to authenticate users against a device shall use best practice cryptography, appropriate to the properties of the technology, risk and usage.

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.

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.

The manufacturer shall make a vulnerability disclosure policy publicly available. This policy shall include, at a minimum: <...>

Disclosed vulnerabilities should be acted on in a timely manner.

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.

All software components in consumer IoT devices should be securely updateable.

When the device is not a constrained device, it shall have an update mechanism for the secure installation of updates.

An update shall be simple for the user to apply.

Automatic mechanisms should be used for software updates.

The device should check after initialization, and then periodically, whether security updates are available.

If the device supports automatic updates and/or update notifications, these should be enabled in the initialized state and configurable so that the user can enable, disable, or postpone installation of security updates and/or update notifications.

The device shall use best practice cryptography to facilitate secure update mechanisms.

Security updates shall be timely.

The device should verify the authenticity and integrity of software updates.

Where updates are delivered over a network interface, the device shall verify the authenticity and integrity of each update via a trust relationship.

The manufacturer should inform the user in a recognizable and apparent manner that a security update is required together with information on the risks mitigated by that update.

The device should notify the user when the application of a software update will disrupt the basic functioning of the device.

The manufacturer shall publish, in an accessible way that is clear and transparent to the user, the defined support period.

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 <...>

For constrained devices that cannot have their software updated, the product should be isolable and the hardware replaceable.

The model designation of the consumer IoT device shall be clearly recognizable, either by labelling on the device or via a physical interface.

Sensitive security parameters in persistent storage shall be stored securely by the device.

Where a hard-coded unique per device identity is used in a device for security purposes, it shall be implemented in such a way that it resists tampering by means such as physical, electrical or software.

Hard-coded critical security parameters in device software source code shall not be used.

Any critical security parameters used for integrity and authenticity checks of software updates and for protection of communication with associated services in device software shall be unique per device and shall be produced with a mechanism that reduces <...>

The consumer IoT device shall use best practice cryptography to communicate securely.

The consumer IoT device should use reviewed or evaluated implementations to deliver network and security functionalities, particularly in the field of cryptography.

Cryptographic algorithms and primitives should be updateable.

Access to device functionality via a network interface in the initialized state should only be possible after authentication on that interface.

Device functionality that allows security-relevant changes in configuration via a network interface shall only be accessible after authentication. The exception is for network service protocols that are relied upon by the device and where the manufacturer <...>

Critical security parameters should be encrypted in transit, with such encryption appropriate to the properties of the technology, risk and usage.

The consumer IoT device shall protect the confidentiality of critical security parameters that are communicated via remotely accessible network interfaces.

he manufacturer shall follow secure management processes for critical security parameters that relate to the device.

All unused network and logical interfaces shall be disabled.

In the initialized state, the network interfaces of the device shall minimize the unauthenticated disclosure of security-relevant information.

Device hardware should not unnecessarily expose physical interfaces to attack.

Where a debug interface is physically accessible, it shall be disabled in software.

The manufacturer should only enable software services that are used or required for the intended use or operation of the device.

Code should be minimized to the functionality necessary for the service/device to operate.

Software should run with least necessary privileges, taking account of both security and functionality.

The device should include a hardware-level access control mechanism for memory.

The manufacturer should follow secure development processes for software deployed on the device.

The consumer IoT device should verify its software using secure boot mechanisms.

If an unauthorized change is detected to the software, the device should alert the user and/or administrator to the issue and should not connect to wider networks than those necessary to perform the alerting function.

The confidentiality of personal data transiting between a device and a service, especially associated services, should be protected, with best practice cryptography.

The confidentiality of sensitive personal data communicated between the device and associated services shall be protected, with cryptography appropriate to the properties of the technology and usage.

All external sensing capabilities of the device shall be documented in an accessible way that is clear and transparent for the user.

Resilience should be built in to consumer IoT devices and services, taking into account the possibility of outages of data networks and power.

Consumer IoT devices should remain operating and locally functional in the case of a loss of network access and should recover cleanly in the case of restoration of a loss of power.

The consumer IoT device should connect to networks in an expected, operational and stable state and in an orderly fashion, taking the capability of the infrastructure into consideration.

If telemetry data is collected from consumer IoT devices and services, such as usage and measurement data, it should be examined for security anomalies.

The user shall be provided with functionality such that user data can be erased from the device in a simple manner.

The consumer should be provided with functionality on the device such that personal data can be removed from associated services in a simple manner.

Users should be given clear instructions on how to delete their personal data.

Users should be provided with clear confirmation that personal data has been deleted from services, devices and applications.

Installation and maintenance of consumer IoT should involve minimal decisions by the user and should follow security best practice on usability.

The manufacturer should provide users with guidance on how to check whether their device is securely set up.

The consumer IoT device software shall validate data input via user interfaces or transferred via Application Programming Interfaces (APIs) or between networks in services and devices.

The manufacturer shall provide consumers with clear and transparent information about what personal data is processed, how it is being used, by whom, and for what purposes, for each device and service. This also applies to third parties that can be involv <...>

Where personal data is processed on the basis of consumers' consent, this consent shall be obtained in a valid way.

Consumers who gave consent for the processing of their personal data shall have the capability to withdraw it at any time.

If telemetry data is collected from consumer IoT devices and services, the processing of personal data should be kept to the minimum necessary for the intended functionality.

If telemetry data is collected from consumer IoT devices and services, consumers shall be provided with information on what telemetry data is collected, how it is being used, by whom, and for what purposes.