--- title: "How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products?" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq/constrained-devices" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq/constrained-devices" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-27" keywords: - "ETSI EN 303 645 constrained devices" - "consumer IoT constrained device" - "ICS IXIT evidence" - "software update support" - "hardware replacement support" - "ETSI EN 303 645" - "constrained devices" - "FAQ" - "ICS and IXIT evidence" --- **[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) --- # How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products? 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. *Artifact Guide* *GLOBAL* *ETSI EN 303 645* ## ETSI EN 303 645 How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products A constrained device is not exempt from ETSI EN 303 645 as a class. Teams need a provision-by-provision rationale tied to the device's physical limits, implemented features, and update support model. Grounded in ETSI EN 303 645 V2.1.1 and ETSI TS 103 701 V2.1.1. Use it as implementation guidance, not for legal interpretation. Short answer: treat constrained-device status as a narrow, documented justification, not a blanket waiver. ETSI EN 303 645 defines constrained devices by physical limits, allows some provisions to be not applicable or not fulfilled only with rationale, and gives specific expectations for products that cannot receive software updates. ## How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products? Start with the ETSI definition. EN 303 645 describes a constrained device as one with physical limitations in processing, communication, storage, or user interaction because of its intended use. The standard gives power supply, battery life, processing power, physical access, limited functionality, limited memory, and limited network bandwidth as examples of limits. That status does not remove the product from the standard. EN 303 645 says its baseline provisions apply across consumer IoT, while recognizing that applicability is device-dependent. A constrained-device decision therefore belongs in the implementation record for the specific provision, product, and feature. - Identify the physical constraint and explain why it arises from intended use, not from an avoidable design shortcut. - Apply each provision normally unless the provision's own condition, product functionality, or documented risk rationale supports a different answer. - Record whether the provision is supported, not supported, or not applicable, with enough detail for an assessor, supply-chain reviewer, researcher, or retailer to understand the decision. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Defines constrained devices and explains that provision applicability depends on the device while EN 303 645 remains a consumer IoT baseline. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Explains that the supplier organization provides ICS and IXIT information and that a test laboratory uses them to derive the test plan. ## When can constrained-device status change an ETSI EN 303 645 answer? Constrained-device status can support a narrower answer where EN 303 645 itself ties the provision to constrained-device limits or where implementation is not possible or not appropriate to the identified security or privacy risk. It is not a blanket exemption from authentication, updates, secure communication, or other baseline topics. The standard gives concrete update-related examples. A non-constrained device shall have a secure update mechanism, while constrained devices that cannot have software updated should have a public rationale, a defined support period, a hardware replacement support period and method, and a product design that is isolable and hardware replaceable. - Do not mark a provision as not applicable merely because the product is small, battery-powered, or low cost. - For authentication, note that EN 303 645 separately conditions brute-force protection on the device not being constrained, but password provisions still apply where passwords are used. - For updates, separate software that is updateable, software that is not updateable, and a constrained product that cannot receive software updates at all. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Grounds the limited constrained-device rationale, the brute-force condition for non-constrained devices, and update provisions 5.3-2, 5.3-14, and 5.3-15. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Grounds the need to test N/A and conditional claims against the DUT, user documentation, IXIT, and identification information. ## What evidence should teams keep for constrained devices? Keep the evidence close to the ICS and IXIT process used by ETSI TS 103 701. The supplier organization identifies the Device Under Test, completes the ICS, provides necessary IXIT information for provisions claimed as supported, and gives enough information for the test laboratory to check consistency and soundness. For each constrained-device decision, the evidence should answer four questions: what is physically constrained, which provision is affected, whether the product supports the provision or has a justified N/A or non-support entry, and what user-facing disclosure exists when software cannot be updated. - Document the DUT, model designation, software version assessed, interfaces, associated service dependencies, and the physical constraint being relied on. - Use the ICS detail field to explain implemented measures, reasons implementation is not possible or appropriate, or the rationale for a true N/A determination. - When software updates are absent for a constrained device, retain the published rationale, defined support period, hardware replacement support period and method, and isolation or replacement plan. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Grounds the ICS support/detail structure and the constrained-device update disclosure and replacement expectations. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Grounds the assessment phases: DUT identification, ICS completion, IXIT completion, ICS verification, assessment, and verdict assignment. ## Primary sources - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary source for the constrained-device definition, baseline applicability, provision 4-1 justification records, update provisions, and Annex B ICS detail guidance. - Quote: "Cases where a provision is not applicable or not fulfilled" - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT identification, supplier organization responsibilities, ICS and IXIT inputs, N/A verification, and test-plan derivation. - Quote: "The TL uses these documents to derive a test plan." ## Topic Guides - [ETSI EN 303 645 Applicability and Scope](/artifacts/global/etsi-en-303-645/applicability-and-scope.md): Decide whether a connected product is in scope of ETSI EN 303 645, define the consumer IoT evidence boundary, and document N/A justifications for assessment. - [ETSI EN 303 645 compliance: ICS, IXIT, evidence](/artifacts/global/etsi-en-303-645/compliance.md): Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and source-linked controls. - [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. - [ETSI EN 303 645 Current Version Tracker](/artifacts/global/etsi-en-303-645/current-version-tracker.md): Track ETSI EN 303 645 version evidence, ETSI deliverable status checks, TS 103 701 assessment alignment, and change triggers for consumer IoT security work. - [ETSI EN 303 645 CVD Workflow for IoT Vulnerability Reports](/artifacts/global/etsi-en-303-645/vulnerability-disclosure-cvd-workflow.md): Source-linked workflow for ETSI EN 303 645 vulnerability disclosure: public policy contents, reporting contact, acknowledgement and status timelines, timely action, and TS 103 701 evidence. - [ETSI EN 303 645 Data Protection Provisions](/artifacts/global/etsi-en-303-645/data-protection-provisions.md): source-linked guide to ETSI EN 303 645 data protection provisions for consumer IoT: personal data security, telemetry transparency, consent, and deletion evidence. - [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. - [ETSI EN 303 645 FAQ: Consumer IoT Security Questions](/artifacts/global/etsi-en-303-645/faq.md): 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. - [ETSI EN 303 645 ICS and IXIT Evidence Template](/artifacts/global/etsi-en-303-645/ics-and-ixit-evidence-template.md): Build a source-linked ICS and IXIT evidence template for ETSI EN 303 645 consumer IoT assessments, with clear separation between EN provisions and TS 103 701 test information. - [ETSI EN 303 645 implementation checklist](/artifacts/global/etsi-en-303-645/implementation-checklist.md): Use this ETSI EN 303 645 implementation checklist to scope a consumer IoT product, record Annex B support statuses, map IXIT evidence, and avoid weak conformance claims. - [ETSI EN 303 645 Implementation Evidence Guide](/artifacts/global/etsi-en-303-645/implementation-evidence.md): Build ETSI EN 303 645 implementation evidence from Annex B support/detail records, TS 103 701 ICS and IXIT inputs, test verdicts, and scoped external evidence. - [ETSI EN 303 645 IoT Applicability Workflow](/artifacts/global/etsi-en-303-645/iot-applicability-workflow.md): Decide whether ETSI EN 303 645 applies to a consumer IoT product, what associated services belong in scope, and how to record justified non-applicability. - [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. - [ETSI EN 303 645 requirements: consumer IoT provision map](/artifacts/global/etsi-en-303-645/requirements.md): Map ETSI EN 303 645 consumer IoT requirements to product scope, Annex B ICS entries, TS 103 701 evidence, and implementation owners. - [ETSI EN 303 645 Secure Update Evidence Workflow](/artifacts/global/etsi-en-303-645/secure-update-evidence-workflow.md): Build secure-update evidence for ETSI EN 303 645 using provision 5.3, Annex B support/detail records, and TS 103 701 ICS, IXIT, and test-plan inputs. - [ETSI EN 303 645 Secure Update Workflow](/artifacts/global/etsi-en-303-645/secure-update-workflow.md): Map ETSI EN 303 645 secure-update provisions into a practical workflow for consumer IoT update mechanisms, support-period disclosures, and TS 103 701 evidence. - [ETSI EN 303 645 Secure Updates and Vulnerability Disclosure](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): source-linked guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and TS 103 701 evidence. - [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. - [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. - [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. - [ETSI EN 303 645 vs EU CRA for Consumer IoT](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-eu-cra.md): Use ETSI EN 303 645 and ETSI TS 103 701 evidence when preparing consumer IoT cybersecurity work that may also need a separate EU CRA legal mapping. - [ETSI EN 303 645 vs RED Cybersecurity Delegated Act](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-red-cybersecurity-delegated-act.md): Compare ETSI EN 303 645 consumer IoT security evidence with RED cybersecurity planning without treating the ETSI baseline as a substitute for RED legal scope. - [ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Compare ETSI EN 303 645 evidence with UK PSTI review needs without assuming the same scope, legal trigger, or assurance route. - [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. - [ETSI TS 103 701 Test Evidence Workflow for EN 303 645](/artifacts/global/etsi-en-303-645/ts-103-701-test-evidence-workflow.md): Build an ETSI TS 103 701 test evidence workflow for EN 303 645 consumer IoT assessments: DUT identification, ICS, IXIT, test plans, verdicts, and external evidence. *Recommended next step* *Placement: after practical guidance* ## Operationalize the answer for constrained devices under ETSI EN 303 645 Use this ETSI EN 303 645 guidance to turn constrained-device rationales into ICS detail, IXIT evidence, update disclosures, and reviewable support decisions. - [Turn the answer into evidence](/solutions/assessment.md): Convert constrained-device rationale into provision-by-provision ICS details, IXIT inputs, and assessor-ready records. - [Ask a scoped follow-up](/solutions/research-copilot.md): Use cited research support when a provision, update path, or non-applicability rationale needs tighter grounding. - [Talk through implementation](/contact.md): Review constrained-device scope, update disclosures, evidence ownership, 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/constrained-devices