--- title: "ETSI EN 303 645 FAQ: Consumer IoT Security Questions" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq/items" author: "Sorena AI" description: "source-linked answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, default passwords, updates, vulnerability disclosure, telemetry, deletion, and TS 103 701 evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 303 645 FAQ" - "consumer IoT security" - "associated services" - "default passwords" - "vulnerability disclosure" - "secure updates" - "ETSI TS 103 701" - "ICS" - "IXIT" - "ETSI EN 303 645" - "IoT product scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 303 645 FAQ: Consumer IoT Security Questions source-linked answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, default passwords, updates, vulnerability disclosure, telemetry, deletion, and TS 103 701 evidence. *Artifact Guide* *GLOBAL* *ETSI EN 303 645* ## ETSI EN 303 645 Frequently Asked Questions Clear answers to common ETSI EN 303 645 questions for consumer IoT product, cloud, app, and evidence teams. Grounded in ETSI EN 303 645 and ETSI TS 103 701 source material. Use it as implementation guidance, not for legal interpretation. ETSI EN 303 645 is a baseline cybersecurity standard for consumer IoT devices and their interactions with associated services. This FAQ explains the practical questions teams usually need to settle before using the standard in product design, supplier reviews, procurement responses, or ETSI TS 103 701-style conformance assessment work. ## Browse sub-FAQ modules ### [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md) ETSI EN 303 645 FAQ on consumer IoT product scope: devices, associated services, constrained devices, out-of-scope industrial uses, ICS, IXIT, and TS 103 701 evidence. - 3 items ### [ETSI EN 303 645 default passwords: what must consumer IoT teams do?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md) ETSI EN 303 645 default password guidance for consumer IoT: unique or user-defined passwords, pre-installed password generation, change mechanisms, brute-force controls, and TS 103 701 evidence. - 3 items ### [ETSI EN 303 645 personal data deletion FAQ for consumer IoT](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md) What ETSI EN 303 645 says about deleting user data and personal data from consumer IoT devices, associated services, apps, and evidence records. - 3 items ### [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md) ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, constrained-device replacement support, model designation, and TS 103 701 evidence. - 3 items ### [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md) ETSI EN 303 645 telemetry guidance for consumer IoT teams: security anomaly examination, IXIT 24-TelData evidence, personal-data minimization, and consumer telemetry disclosures. - 3 items ### [ETSI EN 303 645 test evidence: what should consumer IoT teams keep?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md) ETSI EN 303 645 test evidence guidance for consumer IoT teams: ICS support claims, IXIT detail, TS 103 701 test plans, verdicts, and external evidence checks. - 3 items ### [ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md) What ETSI EN 303 645 requires for consumer IoT vulnerability disclosure policies, report handling, status updates, timely action, and TS 103 701 evidence. - 3 items ### [How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products?](/artifacts/global/etsi-en-303-645/faq/constrained-devices.md) ETSI EN 303 645 constrained-device guidance: what counts as constrained, when non-applicability can be justified, and what evidence should support update and authentication decisions. - 3 items Browse all indexed questions: [/artifacts/global/etsi-en-303-645/faq/items](/artifacts/global/etsi-en-303-645/faq/items.md) ## All FAQ items *Page 1 of 2. Showing 20 of 24 items.* ### [What counts as a consumer IoT product under ETSI EN 303 645?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md#what-counts-as-a-consumer-iot-product-under-etsi-en-303-645) *Module: [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md)* 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. - Start the scope note with the exact device or product family, its network connectivity, and the consumer use case. - Include associated services that are required for the product's intended functionality, such as manufacturer-provided cloud access, telemetry, or a companion mobile app. - Do not stretch the scope to industrial, healthcare, or manufacturing devices unless the product is also a consumer IoT device under the ETSI definition. Sources for this answer: - [ETSI EN 303 645 V2.1.1, clause 1 scope and clause 3 terms](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT device, IoT product, associated services, examples, and out-of-scope industrial use. - [ETSI TS 103 701 V2.1.1, scope](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source confirming that the methodology covers consumer IoT devices, their associated services, and corresponding relevant processes. ### [How should teams document product scope for assessment?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md#how-should-teams-document-product-scope-for-assessment) *Module: [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md)* 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. - Identify the DUT, software version, interfaces, associated services, and relevant supplier-side processes before claiming assessment readiness. - Use the EN 303 645 implementation conformance statement pro forma to record support, non-support, or not-applicable rationale for each provision. - Use the TS 103 701 IXIT structure to point assessors to the evidence needed for conceptual and functional tests. Sources for this answer: - [ETSI TS 103 701 V2.1.1, clauses 4.1 to 4.5](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment methodology source for DUT, SO, TL, ICS, IXIT, conceptual tests, functional tests, and test-plan derivation. - [ETSI EN 303 645 V2.1.1, Annex B](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for the implementation conformance statement pro forma and support-detail rationale. ### [What scope mistakes create weak ETSI EN 303 645 claims?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md#what-scope-mistakes-create-weak-etsi-en-303-645-claims) *Module: [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md)* 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. - Avoid saying a whole product is compliant without naming the assessed device, associated services, provisions, software version, and evidence boundary. - Do not exclude a cloud service or companion app when it is an associated service required for the product's intended functionality. - Record constrained-device and not-applicable decisions as product-specific justifications instead of using generic wording. Sources for this answer: - [ETSI EN 303 645 V2.1.1, clauses 1, 3, and 4](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for constrained devices, product-dependent applicability, and recorded justifications under provision 4-1. - [ETSI TS 103 701 V2.1.1, clauses 1 and 4.2](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source explaining that TSOs are generic because consumer IoT devices are heterogeneous and a suitable test plan must be derived. ### [What does ETSI EN 303 645 require for default passwords?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md#what-does-etsi-en-303-645-require-for-default-passwords) *Module: [ETSI EN 303 645 default passwords: what must consumer IoT teams do?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md)* 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. - List every password-based authentication mechanism for users and machine-to-machine authentication. - For each mechanism, state whether the password is user-defined, unique per device, factory-default only, or not used. - Do not present a product as aligned with provision 5.1 if a universal password remains usable after initialization or reset into an operational state. Sources for this answer: - [ETSI EN 303 645 V2.1.1, clause 5.1](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for provision 5.1-1 on unique or user-defined passwords outside factory default. - [ETSI TS 103 701 V2.1.1, TSO 5.1](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for documenting and testing password-based authentication mechanisms in IXIT 1-AuthMech. ### [How should pre-installed unique passwords be handled?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md#how-should-pre-installed-unique-passwords-be-handled) *Module: [ETSI EN 303 645 default passwords: what must consumer IoT teams do?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md)* 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. - Document the password generation mechanism in IXIT 1-AuthMech, including the authentication mechanism that uses it. - Show that generated passwords are not based on predictable counters, public identifiers, common strings, or obvious device information. - Keep functional evidence that sampled device passwords match the documented generation mechanism. Sources for this answer: - [ETSI EN 303 645 V2.1.1, provision 5.1-2](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for requirements on pre-installed unique per-device password generation. - [ETSI TS 103 701 V2.1.1, test group 5.1-2](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for checking obvious regularities, common patterns, public-information links, complexity, and implementation consistency. ### [What else belongs in a provision 5.1 password evidence pack?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md#what-else-belongs-in-a-provision-51-password-evidence-pack) *Module: [ETSI EN 303 645 default passwords: what must consumer IoT teams do?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md)* 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. - Include user-facing instructions for changing passwords or other authentication values, and verify the old value stops working after change. - Document brute-force prevention for network-addressable authentication, such as delays, limited attempts, suspension, lockout, suitable entropy, or two-factor authentication. - Tie each claim to the assessed device version, user manual, interfaces, onboarding flow, reset behavior, and IXIT entries used by the test plan. Sources for this answer: - [ETSI EN 303 645 V2.1.1, provisions 5.1-4 and 5.1-5](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for changing authentication values and making network brute-force attacks impracticable. - [ETSI TS 103 701 V2.1.1, assessment methodology](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for ICS, IXIT, test-plan derivation, and inconclusive verdicts when required evidence is insufficient. ### [What does ETSI EN 303 645 require for personal data deletion?](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md#what-does-etsi-en-303-645-require-for-personal-data-deletion) *Module: [ETSI EN 303 645 personal data deletion FAQ for consumer IoT](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md)* 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. - Treat device erasure and associated-service removal as two related but distinct deletion paths. - Do not assume a factory reset is enough for every privacy scenario; ETSI gives a shared-use example where resetting the whole device would not be appropriate for deleting one user's personal data. - Keep GDPR statements narrow: EN 303 645 says the functionality is expected to comply with applicable data protection law, including GDPR, but the standard itself presents technical baseline provisions rather than a full legal assessment. Sources for this answer: - [ETSI EN 303 645 V2.1.1, clause 5.11](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT user-data erasure, personal-data removal from associated services, deletion instructions, confirmation, and the caution that factory reset is not always the right mechanism. - [ETSI EN 303 645 V2.1.1, clause 6](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Privacy context for consumer IoT, including clear information about personal data processing, valid consent where consent is the basis, withdrawal capability, and telemetry minimization. ### [What should the user experience include?](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md#what-should-the-user-experience-include) *Module: [ETSI EN 303 645 personal data deletion FAQ for consumer IoT](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md)* 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. - Show the deletion entry point in the relevant device, app, or service interface instead of burying it in support-only processes. - Explain whether the action erases device-stored user data, removes personal data from associated services, deletes an app or account profile, or does more than one of these. - Confirm the result in user-visible language, including any practical consequence such as logout, loss of remote services, or return to factory-default state. Sources for this answer: - [ETSI EN 303 645 V2.1.1, provisions 5.11-3 and 5.11-4](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Source for clear deletion instructions and clear confirmation that personal data has been deleted from services, devices, and applications. - [ETSI TS 103 701 V2.1.1, sample IXIT 25-DelFunc](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - The sample IXIT illustrates deletion-function evidence fields such as description, target type, initiation and interaction, and confirmation for device reset and online-profile removal examples. ### [What evidence should teams keep for assessment?](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md#what-evidence-should-teams-keep-for-assessment) *Module: [ETSI EN 303 645 personal data deletion FAQ for consumer IoT](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md)* 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. - Maintain a personal-data inventory that records what personal data is processed, the purpose, authorized parties, lifecycle, and processing activities where those fields apply. - Maintain a deletion-function record for each deletion route, including the target type and the exact user interaction that initiates it. - Retain screenshots, user documentation, or other visible evidence showing the deletion instructions and the confirmation shown after deletion. Sources for this answer: - [ETSI TS 103 701 V2.1.1, Annex B provision-to-IXIT mapping](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment mapping for provisions 5.11-1 through 5.11-4 and data-protection provisions, including IXIT 21-PersData, IXIT 25-DelFunc, and IXIT 2-UserInfo fields. - [ETSI TS 103 701 V2.1.1, conformance assessment methodology](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Defines the assessment methodology for consumer IoT devices, associated services, and relevant processes against ETSI EN 303 645, including ICS, IXIT, and external evidence concepts. ### [What does ETSI EN 303 645 mean by support period?](/artifacts/global/etsi-en-303-645/faq/support-period.md#what-does-etsi-en-303-645-mean-by-support-period) *Module: [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md)* 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. - State the support period as a concrete period or end date for the consumer IoT product. - Keep the claim limited to security-update support unless separate sources support broader product-support or warranty language. - Tie the support-period statement to the product or model designation users need in order to check update support. Sources for this answer: - [ETSI EN 303 645 V2.1.1, definition of defined support period](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source defining the support period as the time for which a manufacturer provides security updates. - [ETSI EN 303 645 V2.1.1, provision 5.3-16](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source connecting recognizable model designation with checking the support period and update availability. ### [What must be published for users?](/artifacts/global/etsi-en-303-645/faq/support-period.md#what-must-be-published-for-users) *Module: [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md)* 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. - Publish the support period where users can reach it without registration or other access restrictions. - Document the publication path in IXIT 2-UserInfo as "Publication of Support Period", including the information needed to access it. - Check that the public page, product information, app help path, or manual points to the same support period recorded in the assessment evidence. Sources for this answer: - [ETSI EN 303 645 V2.1.1, provision 5.3-13](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source requiring publication of the defined support period in an accessible, clear, and transparent way. - [ETSI TS 103 701 V2.1.1, test group 5.3-13](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for conceptual and functional checks on publication of the defined support period. ### [How should constrained or non-updateable devices be handled?](/artifacts/global/etsi-en-303-645/faq/support-period.md#how-should-constrained-or-non-updateable-devices-be-handled) *Module: [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md)* 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. - For updateable products, publish the defined security-update support period and keep it aligned with update evidence. - For constrained non-updateable products, also publish why software updates are absent and how hardware replacement support works. - Keep replacement-support and isolation evidence separate from general marketing claims so assessors can trace the constrained-device route. Sources for this answer: - [ETSI EN 303 645 V2.1.1, provisions 5.3-14 and 5.3-15](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for constrained devices that cannot be updated, including publication of rationale, replacement support, and isolability. - [ETSI TS 103 701 V2.1.1, IXIT 9-ReplSup and test groups 5.3-14 to 5.3-15](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for replacement-support, isolation, and hardware-replacement evidence for constrained non-updateable devices. ### [What does ETSI EN 303 645 say about telemetry?](/artifacts/global/etsi-en-303-645/faq/telemetry.md#what-does-etsi-en-303-645-say-about-telemetry) *Module: [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md)* 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. - Start by listing the telemetry actually collected by the device and associated services, not by writing a generic monitoring statement. - For each telemetry category, document whether it is used for security anomaly examination or only for another purpose such as performance or stability analysis. - Keep the claim conditional: EN 303 645 does not require every product to collect telemetry, but collected telemetry should be examined for security anomalies. Sources for this answer: - [ETSI EN 303 645 V2.1.1, clause 5.10](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for provision 5.10-1 on examining collected telemetry for security anomalies. - [ETSI TS 103 701 V2.1.1, test group 5.10-1](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for checking that at least one security examination is provided in IXIT 24-TelData and that the telemetry description fits the examination. ### [What evidence should support a telemetry claim?](/artifacts/global/etsi-en-303-645/faq/telemetry.md#what-evidence-should-support-a-telemetry-claim) *Module: [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md)* 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. - Use a TelData entry for each meaningful telemetry category, such as crash logs, update failure signals, failed-login indicators, usage measurements, or stream metadata. - For telemetry used in security monitoring, describe how anomalies are examined and whether the examination is performed by the device or by an associated service. - If a telemetry category is not used for security examination, say so plainly instead of implying that every telemetry feed is security telemetry. Sources for this answer: - [ETSI TS 103 701 V2.1.1, IXIT 24-TelData](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for the telemetry data pro forma fields: ID, description, purpose, security examination, and personal data. - [ETSI TS 103 701 V2.1.1, Annex B required IXIT entries](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source mapping provision 5.10-1 to IXIT 24-TelData fields for description and security examination. ### [How should telemetry personal data and consumer information be handled?](/artifacts/global/etsi-en-303-645/faq/telemetry.md#how-should-telemetry-personal-data-and-consumer-information-be-handled) *Module: [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md)* 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. - Map any personal data in telemetry to IXIT 21-PersData and keep only the data needed for the stated telemetry purpose. - Make the consumer-facing telemetry notice accessible and consistent with the IXIT 2-UserInfo documentation of telemetry data. - When publishing product claims, say that the ETSI evidence supports technical data-protection provisions; do not claim GDPR compliance from EN 303 645 alone. Sources for this answer: - [ETSI EN 303 645 V2.1.1, clause 6 telemetry provisions](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for telemetry personal-data minimization and consumer information requirements. - [ETSI TS 103 701 V2.1.1, test groups 6-4 and 6-5](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for checking telemetry personal-data necessity and consumer information about telemetry processing. ### [What counts as test evidence for ETSI EN 303 645?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md#what-counts-as-test-evidence-for-etsi-en-303-645) *Module: [ETSI EN 303 645 test evidence: what should consumer IoT teams keep?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md)* 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. - Keep the EN 303 645 provision mapping separate from TS 103 701 assessment records. - For each supported provision, retain the ICS support claim and the IXIT information needed to prepare and perform assessment activities. - Tie each test result to the specific DUT, software version, associated services, user documentation, and development or management process in scope. Sources for this answer: - [ETSI EN 303 645 V2.1.1, Annex B ICS pro forma](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for the consumer IoT baseline provisions and the support, not-supported, and not-applicable detail model in the ICS pro forma. - [ETSI TS 103 701 V2.1.1, conformance assessment methodology](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL roles, ICS, IXIT, test-plan derivation, conceptual and functional tests, external evidence, and verdict handling. ### [How should ICS and IXIT evidence be prepared?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md#how-should-ics-and-ixit-evidence-be-prepared) *Module: [ETSI EN 303 645 test evidence: what should consumer IoT teams keep?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md)* 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. - Record "Yes", "N", or "N/A" support values in the ICS with the required detail or justification. - Complete only the IXIT entries needed for provisions claimed as "Yes", but make those entries exhaustive, correct, and distinctly referenced. - Where the IXIT references existing documentation, provide that documentation to the test laboratory instead of relying on an unsupported assertion. Sources for this answer: - [ETSI EN 303 645 V2.1.1, implementation of provisions](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for using the ICS detail column to explain implemented measures, reasons for non-support, and rationales for not-applicable provisions. - [ETSI TS 103 701 V2.1.1, clauses 4.3 to 4.5](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for completing DUT identification, ICS, and IXIT, and for the effect of incomplete IXIT information on test execution. ### [Can existing certificates or third-party reports replace testing?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md#can-existing-certificates-or-third-party-reports-replace-testing) *Module: [ETSI EN 303 645 test evidence: what should consumer IoT teams keep?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md)* 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. - Do not reuse a certificate or report unless its scope covers the same DUT part, feature, software, service, or process needed by the test group. - Keep the external evidence reference in the ICS detail field together with the supporting report or certification details. - Treat external evidence as a TS 103 701 assessment input, not as a blanket EN 303 645 conformance claim for the whole product. Sources for this answer: - [ETSI TS 103 701 V2.1.1, clause 4.7 external evidences](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for when existing certifications or third-party evaluations may be used instead of applying test cases for a test group. - [ETSI TS 103 701 V2.1.1, test group verdicts](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for assigning a test group PASS when external evidence fulfils the clause 4.7 requirements. ### [What must the public vulnerability disclosure policy include?](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md#what-must-the-public-vulnerability-disclosure-policy-include) *Module: [ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md)* 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. - Publish a clear external location for the vulnerability disclosure policy, such as a security page or support path that remains reachable without authentication. - Include contact information that lets security researchers and other reporters submit potential vulnerabilities. - State timelines for initial acknowledgement and for status updates until resolution, avoiding vague process text that gives reporters no expectation. - Keep product documentation, app help, or support pages aligned with the public policy location if those channels direct users to report security issues. Sources for this answer: - [ETSI EN 303 645 V2.1.1, clause 5.2](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI requirement for publishing a vulnerability disclosure policy with reporting contact information and acknowledgement/status-update timelines. - [ETSI TS 103 701 V2.1.1, test cases 5.2-1-1 and 5.2-1-2](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment method for checking that the vulnerability disclosure policy publication is available and publicly accessible through IXIT 2-UserInfo. ### [How should reported vulnerabilities be handled after disclosure?](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md#how-should-reported-vulnerabilities-be-handled-after-disclosure) *Module: [ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md)* 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. - Define how reports are triaged, investigated, confirmed, fixed, mitigated, or escalated for the product and its associated services. - Separate timelines where firmware, cloud service, mobile app, hardware, operating system, or third-party library vulnerabilities follow different paths. - Document who owns each step, including security incident teams, software teams, supplier contacts, and external vendors where relevant. - Avoid claiming a fixed universal remediation deadline unless the evidence supports that timeline for the vulnerability type and deployment route. Sources for this answer: - [ETSI EN 303 645 V2.1.1, provision 5.2-2](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for timely action on disclosed vulnerabilities and the standard's explanation of incident-specific timing. - [ETSI TS 103 701 V2.1.1, test case 5.2-2-1](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment method for IXIT 3-VulnTypes action and time-frame evidence, including responsibilities, third-party involvement, and indicators of timely deployment. ## FAQ Pagination - Canonical index (page 1): [/artifacts/global/etsi-en-303-645/faq/items](/artifacts/global/etsi-en-303-645/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 1 of 2 Pages: [1](/artifacts/global/etsi-en-303-645/faq/items.md) | [2](/artifacts/global/etsi-en-303-645/faq/items/page/2.md) [Next page](/artifacts/global/etsi-en-303-645/faq/items/page/2.md) *Recommended next step* *Placement: after practical guidance* ## Operationalize ETSI EN 303 645 questions Use this FAQ to turn consumer IoT scope, password, update, vulnerability disclosure, telemetry, deletion, and TS 103 701 evidence questions into owned work. - [Open Assessment Autopilot for ETSI EN 303 645](/solutions/assessment.md): Convert ETSI EN 303 645 FAQ answers into accountable tasks, evidence requests, and assessment milestones. - [Research ETSI EN 303 645 source questions](/solutions/research-copilot.md): Use cited ETSI source material to resolve scope, applicability, evidence, and version questions before implementation. - [Talk through ETSI EN 303 645 implementation](/contact.md): Review consumer IoT scope, evidence gaps, owners, and next compliance actions with Sorena. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/faq/items