Search every question across sub-FAQs

ETSI EN 303 645 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. The standard also defines an IoT product as the consumer IoT device plus its associated services.

The scope is broad but not unlimited. ETSI lists examples such as connected children's toys and baby monitors, smoke detectors, door locks, window sensors, IoT gateways, base stations, hubs, wearable health trackers, home automation and alarm systems, connected appliances, and smart home assistants. Devices primarily intended for manufacturing, healthcare, or other industrial applications are outside the document's scope.

For assessment work, ETSI TS 103 701 uses the Device Under Test, or DUT, as the specific consumer IoT device assessed against ETSI EN 303 645. TS 103 701 says test scenarios address DUT functionality, its relation to associated services, and development or management processes.

The supplier organization provides ICS and IXIT information to the test laboratory. The ICS declares capabilities implemented in or supported by the DUT, while the IXIT contains or references the additional information about the DUT and assessment environment that enables appropriate test activities. The test laboratory uses those documents to derive a test plan.

A weak scope claim treats ETSI EN 303 645 as a generic product-security label. The standard is product-specific and provision-specific: applicability can depend on the device, whether it is constrained, whether the functionality exists, and which associated services are part of the product.

Constrained devices need explicit handling. ETSI describes constrained devices as devices with physical limitations in processing, communication, storage, or user interaction, and gives examples such as window sensors and low-powered devices that rely on a base station or hub. If a recommendation is considered not applicable or not fulfilled, provision 4-1 requires a recorded justification.

Provision 5.1-1 applies where passwords are used. In any state other than factory default, each consumer IoT device password must be unique per device or defined by the user. That means a shipped value such as a universal admin password cannot be the operational password after setup.

The standard gives several acceptable patterns: unique pre-installed passwords, requiring the user to choose a password during initialization, or avoiding passwords by using another authentication method. The answer should be scoped to each authentication mechanism, not just to the product as a whole.

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 MAC addresses or Wi-Fi 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 users can authenticate against the device, the device must provide a simple mechanism for the user or administrator to change the authentication value. If the device is not constrained, it must also have a mechanism that makes brute-force attacks on authentication mechanisms via network interfaces impracticable.

For an assessment, TS 103 701 expects the supplier organization to complete ICS and IXIT information 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 of ETSI EN 303 645 is the main deletion section. Provision 5.11-1 says the user shall have functionality so user data can be erased from the device in a simple manner. The standard defines that user data broadly for this context: individual data stored on the IoT device, including personal data, user configuration, and cryptographic material such as user passwords or keys.

Provision 5.11-2 is narrower and service-focused. It says the consumer should have functionality on the device so personal data can be removed from associated services in a simple manner. The examples given by ETSI include transfer of ownership, the consumer wanting to delete personal data, removing a service from the device, and disposal of the device.

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.

ETSI also expects clear confirmation that personal data has been deleted from services, devices, and applications. For a product team, this means the deletion flow should not stop at a hidden backend job or a vague success message; the user should be told what was deleted and where the deletion applied.

ETSI TS 103 701 maps the deletion provisions to concrete 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.

For visitor-facing content, the useful answer should say what security-update support period applies to the product and where a user can find it before or around purchase. Avoid vague statements such as "supported for a reasonable period" if the product evidence does not define a duration or end date.

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 IXIT 2-UserInfo. The assessment checks whether a user with limited technical knowledge can understand and access the publication, whether access is unrestricted, and whether the published support period matches the support-period information documented for updateable software components.

If a constrained device cannot have its software updated, do not treat the support-period answer as complete by saying updates are not available. ETSI EN 303 645 provision 5.3-14 says the manufacturer should publish the rationale for the absence of software updates, the period and method of hardware replacement support, and a defined support period in an accessible, clear, and transparent way.

TS 103 701 separates this evidence from the normal support-period publication. It checks the published rationale for absence of updates and the published hardware replacement support information, including period and method. It also maps replacement-support evidence to IXIT 9-ReplSup for constrained-device isolation and hardware replacement.

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

TS 103 701 turns the telemetry provision into IXIT 24-TelData evidence. The completed IXIT lists telemetry collected by the device and associated services, with an identifier, description, purpose, security examination, and references to any personal data processed in the telemetry data.

For provision 5.10-1, the test laboratory checks whether at least one security examination is provided in IXIT 24-TelData for examining security anomalies. It also assesses whether each associated telemetry description is suited to the described security examination.

EN 303 645 clause 6 is the relevant place to narrow privacy-facing telemetry statements. It says the document addresses personal-data protection from a strictly technical perspective, so teams should avoid broad legal-compliance claims unless they have separate legal grounding.

For collected telemetry, provision 6-4 says personal-data processing should be kept to the minimum necessary for the intended functionality. Provision 6-5 says consumers must be told what telemetry data is collected, how it is used, by whom, and for what purposes.

Start with the distinction between the two ETSI documents. EN 303 645 is the baseline requirements standard for consumer IoT devices and associated services. Its Annex B ICS pro forma lets the user of the standard record whether each provision is supported, not supported, or not applicable, and the detail column explains the implemented measure or rationale.

TS 103 701 is the assessment methodology. It defines the Device Under Test, Supplier Organization, Test Laboratory, ICS, IXIT, test plans, conceptual tests, functional tests, external evidence, and verdict handling. A useful evidence pack therefore should not say only "tested to EN 303 645"; it should show the assessed DUT, the ICS claim, the IXIT detail, the test group or external evidence used, and the verdict basis.

Under TS 103 701, the supplier organization completes identification of the DUT, the ICS, and the necessary IXIT information. The ICS states which EN 303 645 provisions are objects of the assessment. The IXIT contains additional information about the DUT and assessment environment so the test laboratory can choose suitable test methods, equipment, conditions, and instructions.

This means evidence should be specific enough for a test plan. For a provision claimed as "Yes", the IXIT should contain or reference the implemented security measures needed for the corresponding test group. If the IXIT is incomplete or insufficient, TS 103 701 allows an inconclusive verdict because the test case cannot be properly executed.

Sometimes, but only within the TS 103 701 external-evidence rules. Existing security certifications or third-party evaluations of parts of the DUT may be used partially as evidence to reduce assessment effort. The supplier organization has to announce the evidence in the addressed ICS detail field and provide the certification, certification details, test reports, or other information needed for verification.

The test laboratory still has to decide whether the evidence is adequate for the corresponding test group. TS 103 701 says the laboratory examines whether the scope matches the test group objective, whether the evidence's test activities meet each test purpose in the test group, and whether the test depth or evaluation assurance level is appropriate to the level addressed by the test group.

The public policy is not just a security mailbox. EN 303 645 provision 5.2-1 says the manufacturer shall make a vulnerability disclosure policy publicly available and that the policy includes contact information for reporting issues plus a timetable for initial acknowledgement and status updates until reported issues are resolved.

For visitors, buyers, researchers, and assessors, the policy should make the reporting path visible without requiring private documentation. TS 103 701 turns that into both a conceptual and functional assessment: the test laboratory checks the publication route described in IXIT 2-UserInfo and verifies that the policy is publicly accessible.

EN 303 645 provision 5.2-2 says disclosed vulnerabilities should be acted on in a timely manner. The standard explains that timing is incident-specific: software fixes are conventionally completed within 90 days, including patch availability and notification, while hardware fixes can take considerably longer.

That means the evidence should describe the decision path for different vulnerability types rather than using a single generic promise. TS 103 701 expects the test laboratory to assess the action and time frame for each disclosed vulnerability type in IXIT 3-VulnTypes, considering the public disclosure policy, severity, criticality, firmware, hardware or software type, process steps, responsibilities, and third-party involvement.