Questions and answers

ETSI defines a consumer IoT device as a network-connected or network-connectable device that has relationships to associated services and is typically used by consumers in the home or as an electronic wearable. An IoT product is the consumer IoT device plus its associated services. Consumer devices do not leave scope merely because a business also uses them.

Examples include connected children's toys, baby monitors, smoke detectors, locks, window sensors, gateways, hubs, cameras, speakers, televisions, wearable health trackers, home automation and alarms, appliances, and smart home assistants. Devices primarily intended for manufacturing, healthcare, or other industrial applications are outside the document's scope.

ETSI TS 103 701 uses the Device Under Test (DUT) as the specific consumer IoT device submitted for assessment. The test scenarios cover DUT functionality, its relation to associated services, and relevant development or management processes. The most up-to-date DUT software version should be used for the assessment.

The Supplier Organization can be the developer, manufacturer, vendor, or distributor requesting the assessment. It provides the Implementation Conformance Statement (ICS) and Implementation eXtra Information for Testing (IXIT) to the Test Laboratory and coordinates necessary product and supply-chain information. The laboratory uses those records to verify scope, derive a test plan, perform applicable test groups, and assign verdicts.

A weak scope claim treats ETSI EN 303 645 as a generic product-security label. The standard is product- and provision-specific: applicability can depend on a provision's condition, whether a feature exists, which associated services form part of the product, and the exact DUT version.

V3.1.3 no longer defines a general constrained-device category. A use-case resource constraint matters only where a provision makes it relevant, such as the condition in provision 5.1-5. Provision 5.0-1 also requires a recorded justification for each recommendation considered not applicable or not fulfilled.

Provision 5.1-1 applies where passwords authenticate users against the device or provide machine-to-machine authentication. In every state other than factory default, all device passwords must be unique per device or defined by the user. A universal value such as "admin" cannot remain usable as an operational password after initialization.

The standard permits unique pre-installed passwords, a user-selected password during initialization, or another authentication method that does not use passwords. Standard pairing codes are not treated as machine-to-machine passwords. V3.1.3 separately recommends that passwords not be used for machine-to-machine authentication and requires applicable authentication mechanisms to use best-practice cryptography.

Apply the test to every password-bearing path. Check local administration, remote application programming interfaces (APIs), network protocols, companion-app handoffs, service credentials used by the device, initialization, recovery, and factory reset. Record which state each credential is usable in and whether reset restores a unique value or forces a user-defined value before normal operation.

Provision 5.1-2 applies when pre-installed unique per-device passwords are used. The generation mechanism must reduce the risk of automated attacks against a class or type of device, so the evidence has to cover the generation method, not only a sample label or onboarding screenshot.

ETSI gives examples of weak patterns to avoid: incremental counters, common strings, and passwords obviously related to public information such as media access control (MAC) addresses or Wi-Fi network names (SSIDs). TS 103 701 turns that into conceptual checks on regularities, common patterns, relationship to public information, and appropriate complexity.

Default-password work is only one part of clause 5.1. If a user can authenticate against the device, provision 5.1-4 requires a simple way for the user or an administrator to change the authentication value, whether that value is a password, personal identification number (PIN), biometric, or other token. Provision 5.1-5 requires a mechanism that makes successful brute-force attacks through network interfaces impracticable unless a resource constraint determined by the use case prevents implementation.

For an assessment, TS 103 701 expects the supplier organization to complete the Implementation Conformance Statement (ICS) and Implementation eXtra Information for Testing (IXIT) so the test laboratory can derive a test plan. Incomplete IXIT information can lead to an inconclusive test result because the test case cannot be properly executed.

Clause 5.11 separates mandatory device erasure from recommended service deletion. Provision 5.11-1 says users shall have functionality to erase all their user data from the device in a simple manner. Here, user data means data stored on the device that the user created or that the device generated through user activity, including personal data, configuration, event logs, and cryptographic material such as passwords or keys. It excludes data present before the user's first use.

Provision 5.11-2 says the consumer should have functionality on the device to delete personal data from associated services in a simple manner. Relevant moments include ownership transfer, a personal-data deletion request, removal of a service, and device disposal. "Simple" means minimal steps, each with minimal complexity.

The explanatory text says a consumer who requests complete deletion also expects retrospective deletion of backup copies. Treat backup handling as part of the product's deletion design and evidence, but do not present that explanation as a separate mandatory EN 303 645 provision. Applicable law or another requirement may independently control whether particular records must be deleted or retained.

The standard uses simple, user-facing language. Deletion should require minimal steps and minimal complexity, and users should receive clear instructions on how to delete their personal data.

Provision 5.11-4 recommends clear confirmation that personal data has been deleted and, where possible, erased from devices and associated services. The current edition does not list applications as a separate confirmation target. An app may still be part of the device or an associated service, but the product boundary must establish that.

ETSI TS 103 701 maps the deletion provisions to concrete Implementation eXtra Information for Testing (IXIT) entries. For 5.11-1, the required deletion-function evidence includes an ID, description, target type, and initiation and interaction. For 5.11-2, teams also need personal-data evidence that describes the personal data and processing activities, linked to the deletion functionality.

For 5.11-3 and 5.11-4, the evidence extends to user information: documentation of deletion, personal-data and deletion-function entries, and confirmation evidence. The useful evidence packet therefore joins three views: the personal data inventory, the deletion function, and the user-facing documentation or confirmation.

The support period is not a general warranty promise. ETSI EN 303 645 defines it specifically around security updates: the minimum length of time, expressed as a period or by an end date, for which the manufacturer will provide security updates.

The public statement should identify the product or model and give either a duration with a clear start point or a specific end date. Avoid wording such as "supported for a reasonable period": it does not tell a buyer when security-update support ends.

EN 303 645 does not prescribe a universal minimum number of months or years. The manufacturer defines the period for the product and publishes it. Other laws, contracts, procurement terms, assurance schemes, or product-specific standards may impose a different or longer commitment and need separate review.

Provision 5.3-13 requires the manufacturer to publish the defined support period in an accessible, clear, and transparent way. The surrounding ETSI text explains why: when purchasing a product, the consumer expects the period of software-update support to be clear.

TS 103 701 makes this assessable through Implementation eXtra Information for Testing (IXIT) 2-UserInfo and the software-component information in IXIT 6-SoftComp. The laboratory checks whether a user with limited technical knowledge can understand and access the publication, whether access is unrestricted, and whether the published statement matches the documented support period.

If a device cannot have its software updated, do not stop at saying updates are unavailable. Provision 5.3-14 recommends publishing the reason, plus the period and method of hardware replacement support, in an accessible, clear, and transparent way. The mandatory defined support period under 5.3-13 still applies.

V3.1.3 applies this route to any device that cannot have its software updated; it is no longer limited to a defined constrained-device class. Provisions 5.3-15A and 5.3-15B also recommend that such a device be isolable and that its hardware be replaceable. TS 103 701 maps the replacement and isolation evidence to IXIT 9-ReplSup.

EN 303 645 defines telemetry as data from a device that can help the manufacturer identify issues or information related to device usage. Provision 5.10-1 is a recommendation that applies when telemetry is collected from the IoT product, including usage and measurement data. It does not require telemetry collection.

The standard gives practical examples of the kind of security signal it expects teams to look for: deviations from normal device behaviour, such as an abnormal increase in failed login attempts, or telemetry across multiple devices showing that updates are failing because software update authenticity checks are invalid.