ETSI EN 303 645 Constrained Devices

Start with the edition. EN 303 645 V2.1.1 defined a constrained device through physical limits in processing, communication, storage, or user interaction. EN 303 645 V3.1.3 no longer defines or uses that category as a general applicability shortcut.

The current edition still recognizes resource limits where a provision says they matter. For example, provision 5.1-5 requires protection that makes successful brute-force attacks through network interfaces impracticable unless a resource constraint determined by the use case prevents implementation. Update provisions 5.3-14, 5.3-15A, and 5.3-15B apply to devices that cannot have their software updated, whether or not a team calls them constrained.

A resource constraint changes an answer only where the current provision or ICS condition makes that fact relevant. Provision 5.0-1 separately requires a justification for each recommendation considered not applicable or not fulfilled; it does not authorize a blanket exception from mandatory requirements.

For updates, distinguish three questions. Provision 5.3-2 requires a secure update mechanism unless a resource constraint determined by the use case prevents implementation. Provision 5.3-13 requires every manufacturer to publish the defined security-update support period. If a device cannot have its software updated, provision 5.3-14 recommends publishing the reason and hardware-replacement support period and method, while 5.3-15A and 5.3-15B recommend that the device be isolable and its hardware replaceable.

Keep the evidence close to the ICS and IXIT process used by ETSI TS 103 701. The supplier organization identifies the Device Under Test (DUT), 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 resource-constraint or non-updateable-device decision, the evidence should answer four questions: what product fact changes the provision, which ICS condition or feature applies, what support value and detail are recorded, and what public disclosure or replacement procedure is required.

Use a provision-by-provision sequence: test the condition or feature first; record Y, N, or N/A with its rationale; provide the required IXIT detail for claims of support; then check whether a public support-period, no-update rationale, replacement method, isolation procedure, or hardware-replacement procedure is also expected.